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

From: Balázs Kovács <[email-masked]>
Date: Wed, 3 Apr 2019 11:18:17 +0000

Hi,

I agree with Juergen's view to add possibility of generating keys with an action that becomes (protected) configuration.

See more below.

/Balazs

> -----Original Message-----
> From: Juergen Schoenwaelder <[email-masked]>
> Sent: Friday, March 29, 2019 9:53 PM
> To: Kent Watsen <[email-masked]>
> Cc: Balázs Kovács <[email-masked]>; tom petch
> <[email-masked]>; [email-masked]
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> 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
> 
> On Fri, Mar 29, 2019 at 08:25:26PM +0000, Kent Watsen wrote:
> > Hi Balazs,
> >
> > > 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.
> >
> > 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. 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?
> >
> > 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).

Yes. Correct. 

> >
> > 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/OtYAlqLmlErfCr3Z4mcXqRvez
> 48
> <https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRve
> z48>.
> >
> > 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 see, and agree. With the suggestion to make it mean "inaccessible via YANG interface" I think I rather meant all interface exposed to the same type of actor. For example if YANG interface is an external operator interface, then the key should of course be consistently inaccessible on all other type of external operator interface.

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

OK.

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

OK.

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

I'm fine with your proposal. I have no issues with actions generating configuration (but I never followed the discussions about actions and datastores) --that is relevant for backup--and we see the example of this keystore use case and also the user management use case Juergen brought up.

> > Thoughts?
> >
> > Kent // contributor
> >
> >
> >
> 
> --
> 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: Martin Bjorklund <[email-masked]>
Date: Wed, 03 Apr 2019 13:44:24 +0200 (CEST)

Hi,

>   storage (and never be accessible)

So, the current model supports 1 and 3 above.

Do we have to support 2?  (and what does "(protected) configuration"
mean?  is this different from "configuration"?)

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

AFAIK there is no standard model defined that actually do this.

The closest thing we have is the "type" of an interface:

           When an interface entry is created, a server MAY
           initialize the type leaf with a valid value, e.g., if it
           is possible to derive the type from the name of the
           interface.

If private keys are handled like this, then I can accept it.  But we
should NOT introduce special actions/rpcs that manipulate the
configuration.

/martin

> > > 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.
> > 
> > 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. 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?
> > 
> > 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 {
> > 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
> > 
> > 
> > 
> 
> -- 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Apr 2019 14:09:58 +0200

> mean?  is this different from "configuration"?)

My understanding is that this is being done. Protected configuration
means that the private key becomes configuration (config true) but the
private config true key is protected via nacm:default-deny-all.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Apr 2019 16:23:23 +0000

> AFAIK there is no standard model defined that actually do this.

Mostly true, though one might claim that <edit-config> is an example 
of an RPC that modifies configuration.

> If private keys are handled like this, then I can accept it.  

This is not what is being asked for here.

> But we

Why not?  Not that it's a valid justification, but vendors do it already.
What would it take to make it be not "special"?   Would adding a
standard (yang-next?) "modifies-configuration" leaf to the action/rpc
definition suffice?

FWIW, I do agree with Balazs, and argued as much a couple years
ago, that the current approach is not best practice.  That said, I'm
more interested in the general-purpose use of rpcs/actions this way.

We have always said no, but the reasoning is unclear.  What are the
specific objections and is there anyway to alleviate them?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Apr 2019 18:49:29 +0200

> specific objections and is there anyway to alleviate them?

If editing of all configuration can be done with a single edit-data
(or edit-config) operation, you simplify the world and you enable
generic implementations.

Once you build silos of data that can only be manipulated with special
purpose operations, you say goodbye to the idea of generic client
libraries.

/js

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 4 Apr 2019 16:51:33 +0000

Hi Kent,

Inline with [RW]

From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 04 April 2019 17:23
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] ietf crypto types - permanently hidden

[RW]
But in this case, the updated configuration is provided by the client, not the server.  I.e. it is clear which entity owns the configuration, and is the "source of truth".

But we

[RW]
I think that is bad practice for a server to inject configuration into <running>.  It makes it ambiguous as to which entity really owns the configuration.   I think that what is in <running> should be owned by the client, not the server.  I'm not saying that nobody does this, but I don't believe that it is the cleanest solution.

I'm OK with a server injecting configuration between <running> and <intended>, and using NACM to prevent that value from being read back from <intended>.

I'm OK with the server just reporting the default system allocated value in <operational>, again protected by NACM if appropriate.

Thanks,
Rob

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Apr 2019 17:12:36 +0000

> [RW]
> I think that is bad practice for a server to inject configuration into <running>.  It makes it ambiguous as to which entity really owns the configuration.   I think that what is in <running> should be owned by the client, not the server.  I’m not saying that nobody does this, but I don’t believe that it is the cleanest solution.
> 

We're not talking about the server doing something on its own accord here; this would be a direct result of a client request.  Abstractly, such can be considered configuration as legitimate as configuration provided by any other means.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Apr 2019 17:24:17 +0000

> purpose operations, you say goodbye to the idea of generic client

Fair, so what can we do to ensure this doesn't spiral out of control?

Clearly there is some line being crossed here (a Security best practice)
that is driving this.   Could we add that such use MUST only be done in 
order to resolve a Security best practice?

That said, I think your fear is unwarranted.  I do not believe that folks
would rush to defined 1000s of RPCs.   It seems that such use would
be done only in extenuating circumstances.

And, besides, so what?  Why do we care if people do stupid things?
Do we feel that our obligation to prevent people from doing stupid
things is more important than enabling people to do smart things?

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Apr 2019 19:46:23 +0200 (CEST)

> purpose operations, you say goodbye to the idea of generic client

And you can no longer create all required config in one transaction;
you have to split it into sending multiple special-purpose actions.
Perhaps also in a certain order, that you have to figure out somehow,
since config might have refererences to other partf of the config
etc.

You can no longer restore a backup with just a copy-config.

So I don't think the reasoning is unclear at all.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 4 Apr 2019 18:20:28 +0000

> On Apr 4, 2019, at 1:46 PM, Martin Bjorklund <[email-masked]> wrote:
> 

This is a good start to a list of limitations that could be added to
a description statement.  Let people decide.  In this case, not a 
big deal.

Kent // contributor

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 5 Apr 2019 10:14:30 +0000

Hi Kent,

But clients are also allowed to explicitly configure public and private keys in the configuration?  (I.e. the “upload of keys” previous described).

If a private key is uploaded in the configuration, would that private key still be readable by the client in <running>, <intended>?  Or would that also be blocked via NACM by default?

I’m trying to understand once the keys are generated, how these two cases differ?

1) upload of keys

2) generation of keys on the box that become (protected) configuration

If a client does not want to explicitly upload keys then are they forced to explicitly do (2) to generate keys?  Or could the system automatically generate persistent keys?

Thanks,
Rob

From: Kent Watsen <[email-masked]>
Sent: 04 April 2019 18:13
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]
Subject: Re: [netconf] ietf crypto types - permanently hidden

[RW]

Kent // contributor

---

From: tom petch <[email-masked]>
Date: Fri, 5 Apr 2019 10:48:36 +0000

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 04, 2019 6:46 PM

> You can no longer restore a backup with just a copy-config.

Which is exactly what I have seen customers - think military - do.

Security-related information - userid, passwords, second factor , ...-
MUST NOT be backed up like everything else - special procedures -
authentication, encryption -  must be used.

This is security - it matters.

Tom Petch

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 05 Apr 2019 14:22:01 +0200 (CEST)

> authentication, encryption -  must be used.

Agreed!  BUT, then it should not be modelled as configuration, imo.

And the current model already handles this case with "hidden" keys.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 5 Apr 2019 14:53:47 +0000

Hello,

While using actions to configure data nodes instead of
edit-config clearly has problems, in some cases it is needed.
Ericsson does use it, but we try to be VERY(!) restrictive when it
is allowed. IMHO  security best practice could be one case. Also
we should not pretend this is the only case where the system
itself manipulates configuration:

security keys

HW insertion/removal (interface type)

onboard automation may do it

server capabilities that need additional configuration (must
be in running as it is reference from other parts of the
configuration)

I also hope we will arrive at a solution that works for non-NMDA
systems too. AFAIK  we never stated in any RFC that NMDA is a
requirement for the solution. (Except for NMDA itself :-)  )

regards Balazs

On 2019. 04. 05. 14:22, Martin
Bjorklund wrote:

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 04, 2019 6:46 PM

We have always said no, but the reasoning is unclear. What are

the

Once you build silos of data that can only be manipulated with

special

/martin

Tom Petch

/martin

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Balázs Kovács <[email-masked]>
Date: Wed, 24 Apr 2019 12:52:34 +0000

Hi,

Is there a conclusion on this thread?

Alternatives I’ve seen:

  1.  ‘hidden’ actions already solve the problem.
     *   Backup of keys won’t be supported or special procedure needed.
     *   Descriptions need to be updated to generalize use case (not be restricted to TPMs).
  2.  Current actions solve the problem, but new terminology should be needed instead of ‘hidden’ and ‘permanently hidden’.
     *   Backup of keys won’t be supported or special procedure needed.
     *   Descriptions to be updated.
  3.  New actions needed that affect configuration for non-TPM use cases
     *   Backup of keys can be supported

                                                               i.      Q: how does a restore differ from normal configuration which the generate key action was supposed to circumvent to follow security best practice?

I guess the latest mails confirm 1) or 2). Would be good to know the way forward.

Br,
Balazs

From: netconf <[email-masked]> On Behalf Of Balázs Lengyel
Sent: Friday, April 5, 2019 4:54 PM
To: Martin Bjorklund <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [netconf] ietf crypto types - permanently hidden

Hello,

While using actions to configure data nodes instead of edit-config clearly has problems, in some cases it is needed. Ericsson does use it, but we try to be VERY(!) restrictive when it is allowed. IMHO  security best practice could be one case. Also we should not pretend this is the only case where the system itself manipulates configuration:

  *   security keys
  *   HW insertion/removal (interface type)
  *   onboard automation may do it
  *   server capabilities that need additional configuration (must be in running as it is reference from other parts of the configuration)

I also hope we will arrive at a solution that works for non-NMDA systems too. AFAIK  we never stated in any RFC that NMDA is a requirement for the solution. (Except for NMDA itself :-)  )

regards Balazs
On 2019. 04. 05. 14:22, Martin Bjorklund wrote:

tom petch <[email-masked]><mailto:[email-masked]> wrote:

----- Original Message -----

From: "Martin Bjorklund" <[email-masked]><mailto:[email-masked]>

To: <[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]>

Juergen Schoenwaelder <[email-masked]><mailto:[email-masked]> wrote:

the

generic implementations.

special

libraries.

etc.

/martin

Tom Petch

/martin

netconf mailing list

[email-masked]<mailto:[email-masked]>

netconf mailing list

[email-masked]<mailto:[email-masked]>

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Apr 2019 16:07:12 +0000

Regarding #1, per previous discussion, the 'permanently-hidden' text regarding such keys not being backed up or restored has been replaced (see below).  With regards to permanently hidden keys, I think the current solution with the 'generate-hidden-key' and 'install-hidden-key' is nearly ideal, if not so.

        type enumeration {
               hardware module).

               How such keys may be backed-up and restored,
               if at all, is application specific.
               
               Servers MUST fail any attempt by a client to
               configure this value directly.  This value is
               not set by clients, but rather is set by the
               'generate-hidden-key' action.";
          }
        }

Regarding #2, I'm unclear how a different name would be any better than "hidden".  From the above description text, the key surely seems "hidden" (from the YANG-driven management engine) to me...

Regarding #3, firstly note that the description text doesn't necessitate use of a TPM, it is merely suggestive that may a motivating reason.  Second, I'm unsure if "new actions" are needed so much as a "new approach" or maybe "different actions" (is this what you meant?). 

To dig into this again, it is common best practice to have a device generate a private key that is considered configuration, albeit protected by access-control.  The reason for this best practice is that it supports the private key never having to exist outside the device (backups and HA-replication withstanding) and, in particular, the client doesn't touch the key (there are no remnants on the client computer needing to be scrubbed).  

In addition to the best-practice angle, there's also a simplicity aspect in that invoking an action is much easier (and perhaps safer) than the client using a crypto-library.  In fact, the only reason a client might not want the server generate the private key is because of a lack of confidence in the server's key-generation implementation (e.g., the strength of the entropy, though TPM-generated entropy is rather excellent).   

To be clear, I also support enabling clients to generate private keys themselves, as there are times when it is important, but feel that it should be viewed as a special case rather than common procedure.

My recommendation is to modify the "generate/install-hidden-key" (renamed to just "generate/install-key") actions to have a flag indicating if the key should be "permanently hidden" (perhaps by using a TPM) or not, in which case configuration is created, same as if the client had used <edit-config>, but without needing to touch the key.

Yes, having an action generate config is a taboo subject, the general reasoning for which is understood [1], but it seems that exceptions should be made in special circumstances, such as this one.

[1] https://mailarchive.ietf.org/arch/msg/netconf/ezf5o9GvCsH_hDPiIX-YQKfnxj8

Kent // contributor

> On Apr 24, 2019, at 8:52 AM, Balázs Kovács <[email-masked]> wrote:
> 
> Hi,
>  
> ‘hidden’ actions already solve the problem. 
> Backup of keys won’t be supported or special procedure needed.
> Descriptions need to be updated to generalize use case (not be restricted to TPMs).
> Current actions solve the problem, but new terminology should be needed instead of ‘hidden’ and ‘permanently hidden’.
> Backup of keys won’t be supported or special procedure needed.
> Descriptions to be updated.
> New actions needed that affect configuration for non-TPM use cases
> Backup of keys can be supported
> From: netconf <[email-masked] <mailto:[email-masked]>> On Behalf Of Balázs Lengyel
> To: Martin Bjorklund <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> server capabilities that need additional configuration (must be in running as it is reference from other parts of the configuration)
> tom petch <[email-masked]> <mailto:[email-masked]> wrote:
>  
> From: "Martin Bjorklund" <[email-masked]> <mailto:[email-masked]>
> To: <[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]>
> Juergen Schoenwaelder <[email-masked]> <mailto:[email-masked]> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>  
>  
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>  
> -- 
> Mobile: +36-70-330-7909              email: [email-masked] <mailto:[email-masked]> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Apr 2019 20:05:13 +0200

>                if at all, is application specific.

Perhaps this should say 'implementation specific' instead 'application
specific'.

> My recommendation is to modify the "generate/install-hidden-key" (renamed to just "generate/install-key") actions to have a flag indicating if the key should be "permanently hidden" (perhaps by usi…

I agree that having a flag to control the behavior is useful and I
think there should be explicit text how the action fails in case the
requested action cannot be performed.

I am not sure I understand install-hidden-key. The description says:

           "Requests the device to load the specified values into
            a hidden key.  The resulting asymmetric key values are
            considered operational state and hence present only in
            <operational>.";

So what is the persistence model of this? Does a key installed with
install-hidden-key survive reboots? If so, can I delete somehow such a
hidden key? (Is the answer that this key is tied to the lifetime of
the list element indirectly using this grouping?) Does invoking
install-hidden-key twice cause the first installed key to be
overwritten? Can the install-hidden-key action fail in any way?

This leads to related questions for generate-hidden-key: Does invoking
this action twice cause an existing key to be overwritten? Can I
explicitely delete a generated hidden key? Does deleting the list item
that directly or indirectly uses this grouping delete a hidden key?

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Apr 2019 20:29:43 +0000

Hi Juergen,

> Perhaps this should say 'implementation specific' instead 'application

Changed in my local copy.

> that directly or indirectly uses this grouping delete a hidden key?

[Disclaimer: the below reflect my understanding of how the current model works, and does not necessarily reflect if we were to flip things around by letting the actions generate configuration.]

The expectation is that the "permanently hidden" keys would persist, presumably with origin=system.

In the YANG, the "permanently-hidden" enum only appears in the "asymmetric-key-pair-grouping" grouping.   Consuming data models are expected to "use" this grouping under a "config true" node.  This grouping's description statement is noteworthy:

 grouping asymmetric-key-pair-grouping {
    description
      "A private/public key pair.
         
       The 'algorithm', 'public-key', and 'private-key'  nodes are
       not mandatory because they MAY be defined in <operational>.
       Implementations SHOULD assert that these values are either
       configured or that they exist in <operational>.";
    ...
 }

Thusly it is expected that the client will create the parent node (e.g., via <edit-config>) and then invoke either the generate or install hidden key action.  Presumably, the lifetime of the permanently hidden key would be tied to the lifetime of its parent.

Regarding what happens when the actions are invoked a second time, it's not specified.  One choice, perhaps the safe choice, would be to deny subsequent attempts, forcing the client to create a new parent node instead.  If the parent node is in a list, such as in the keystore, then the second key could be created, with certificates bound to it, before mapping reference to the old-key to the new-key.  However, if the key is not in a list, such as when using a "local-definition", then in in-place migration, along with service disruption, would be required.

Of course, one has to ask how often/likely is it that a client wants to regenerate the private key.  Presumably it would only be due to the concern that the key had been compromised (which shouldn't happen if "permanently hidden") or, perhaps, due to a proactive key-rotation policy, thinking (misguided, I believe, proven false now) that the private key's entropy expires over time.  Regardless, the point is that it seems to be an action that would seldomly occur and, when/if it does, the effort to create another parent node (in keystore or a local-definition) might not be a big deal.

PS: words such as "expectation" and "presumably" are used above to indicate a likely need for the text to be more explicit.

Kent // contributor

---

From: Balázs Kovács <[email-masked]>
Date: Mon, 29 Apr 2019 12:24:45 +0000

Hi,

Kent, I'm fine with your proposals.

Regarding subsequent calls to the actions, I agree the safe choice would be to deny them; otherwise, one could run into invalid key pairs (where a certificate was already configured) and authentication failures with network peers (especially in SSH-key-based-authentication case). 

Br,
Balazs

> Sent: Wednesday, April 24, 2019 10:30 PM
> To: Juergen Schoenwaelder <[email-masked]>
> Cc: Balázs Kovács <[email-masked]>; [email-masked]
> >> My recommendation is to modify the "generate/install-hidden-key"
> (renamed to just "generate/install-key") actions to have a flag indicating if
> the key should be "permanently hidden" (perhaps by using a TPM) or not, in
> which case configuration is created, same as if the client had used <edit-
> config>, but without needing to touch the key.
> >
> [Disclaimer: the below reflect my understanding of how the current model
> works, and does not necessarily reflect if we were to flip things around by
> letting the actions generate configuration.]
> 
> In the YANG, the "permanently-hidden" enum only appears in the
> "asymmetric-key-pair-grouping" grouping.   Consuming data models are
> expected to "use" this grouping under a "config true" node.  This grouping's
> description statement is noteworthy:
> 
> Thusly it is expected that the client will create the parent node (e.g., via
> <edit-config>) and then invoke either the generate or install hidden key
> action.  Presumably, the lifetime of the permanently hidden key would be
> tied to the lifetime of its parent.
> 
> Regarding what happens when the actions are invoked a second time, it's
> not specified.  One choice, perhaps the safe choice, would be to deny
> subsequent attempts, forcing the client to create a new parent node instead.
> If the parent node is in a list, such as in the keystore, then the second key
> could be created, with certificates bound to it, before mapping reference to
> the old-key to the new-key.  However, if the key is not in a list, such as when
> using a "local-definition", then in in-place migration, along with service
> disruption, would be required.
> 
> Of course, one has to ask how often/likely is it that a client wants to
> regenerate the private key.  Presumably it would only be due to the concern
> that the key had been compromised (which shouldn't happen if
> "permanently hidden") or, perhaps, due to a proactive key-rotation policy,
> thinking (misguided, I believe, proven false now) that the private key's
> entropy expires over time.  Regardless, the point is that it seems to be an
> action that would seldomly occur and, when/if it does, the effort to create
> another parent node (in keystore or a local-definition) might not be a big
> deal.
> 
> PS: words such as "expectation" and "presumably" are used above to
> indicate a likely need for the text to be more explicit.
> 
> Kent // contributor
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 29 Apr 2019 16:17:51 +0000

Okay, I've added the following text into the generate/install-hidden-key descriptions:

OLD:
         The resulting asymmetric key values are
         considered operational state and hence present only in
         <operational>.";

NEW:
         The resulting asymmetric key values are
         considered operational state and hence present only in
         <operational> and bound to the lifetime of the
         parent 'config true' node.  Subsequent invokaions of
         this or the '<other>-hidden-key' action are denied.";

    where <other> is the name of the other action (generate vs. install).

Kent

> On Apr 29, 2019, at 8:24 AM, Balázs Kovács <[email-masked]> wrote:
> 
> Hi,
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Apr 2019 19:05:55 +0200

>     where <other> is the name of the other action (generate vs. install).

Is it sufficiently clear what 'is denied' means, i.e., how a server
has to report the failure of the action?

/js

PS: s/invokaions/invocations/

---

From: Kent Watsen <[email-masked]>
Date: Mon, 29 Apr 2019 17:28:25 +0000

> has to report the failure of the action?

Shall we use the 'data-exists' error-tag?

> PS: s/invokaions/invocations/

Fixed.

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 30 Apr 2019 11:30:19 +0000

Hi Kent,

I don’t see the your proposal below addressed in latest update  (keystore-09). Was it missed?

Br,
Balazs

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Apr 2019 12:03:50 +0000

Correct, as I didn’t think there was consensus yet.  Perhaps there is rough-consensus, and it may be that the only way to gauge that is to try and see how much push back there is.

Okay, so how about this, based on this thread, there appears to be support to add a flag to control if a key should be “permanently hidden” or not, in which case configuration is created.

This change will be in the next update, in about a week’s time, if no objections are raised.

Kent // contributor

> On Apr 30, 2019, at 7:30 AM, Balázs Kovács <[email-masked]> wrote:
> 
> Hi Kent,
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Apr 2019 14:49:30 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 
> Correct, as I didn’t think there was consensus yet.  Perhaps there is
> rough-consensus, and it may be that the only way to gauge that is to
> try and see how much push back there is.
> 
> Okay, so how about this, based on this thread, there appears to be
> support to add a flag to control if a key should be “permanently
> hidden” or not, in which case configuration is created.

I (still) object to this.  Actions shouldn't create config.  We
already have generic protcol operations to do this.  We go from a
document-oriented configuration model towards a command-oriented
model.  Not good.  In RESTCONF, the generic methods support things
like ETags, which I suspect you don't want to replicate in this
action?   Will the action support all error-options of edit-config,
like rollback-on-error?

Some comments on the new text:

In action generate-hidden-key, it should be stated that the public-key
will be populated, and that the private-key will exist but report
'permanently-hidden'.

In action install-hidden-key, shouldn't both public-key and
private-key be mandatory?  Also state that the private-key will report
'permanently-hidden'.

In leaf private-key, the type binary part of the union doesn't have a
description, and the description for the leaf itself says:

       A binary that contains the value of the private key.

which is not quite correct.

I think we should state that the enum 'permanently-hidden' is only
reported in operational state.

The new descriptions say:

            [...] present only in
            <operational> and bound to the lifetime of the parent
            'config true' node.

Aren't all nodes bound to the lifetime of their parent?
The action is invoked in a node that exists in <operational> and it
creates a key.  What does the statement tell me?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Apr 2019 18:12:23 +0200

> action?   Will the action support all error-options of edit-config,

Martin,

do you have any proposal how to support the requirement to generate a
key on the device that is workable with a document-oriented
configuration model? Do you propose that the action/rpc returns the
public key information as result data that then needs to be written
back to the server and somehow matched to the key that is cached on
the device? Perhaps you have other ideas I can't think of?

I think I would be happy to not have this special hack but then we
need a workable alternative. Key generation on devices is something
that is being used - and may be even more used in the future the more
we get special hardware support for storing keys.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Apr 2019 17:57:07 +0000

> action?   Will the action support all error-options of edit-config,

The specifics for how this could work would need to be defined.  Given that it is a special case, I think that we could constrain it heavily and target simple solution.   Depending how much text is required to describe it, it might be good to define an extension statement that could be placed on the actions.  While an extension statement may seem like it opens the gates for general use, we could further define the extension statement as being something that MUST NOT be used when general purpose operations are suitable such that, at least with the IETF, it could only be used in extraordinary circumstances.

> will be populated, and that the private-key will exist but report

Okay, but before making the edit, see comment below about lifetimes...

> private-key be mandatory?  Also state that the private-key will report

Indeed, fixed.

> reported in operational state.

The 'type' statement doesn't have 'description' as a substatement, 
but, point taken, two updates:

In leaf private-key:
  OLD:
      A binary that contains the value of the private key.
  NEW:
      Either a binary that contains the value of the private key or, in 
      the case of a hidden key, the value 'permanently-hidden'.

In enum permanently-hidden:
  OLD:
       The private key is inaccessible due to being protected by the
       system (e.g., a cryptographic hardware module).
  NEW:
       The private key is inaccessible due to being protected by the
       system (e.g., a cryptographic hardware module).  Since hidden
       keys are only ever reported in <operational>, the value
       'permanently-hidden' never appears in <intended>.

> creates a key.  What does the statement tell me?

This seems like something new (and maybe wrong) and hence needs to be explained.  This seems new because we are saying that the lifetime of an operational value is tied to the lifetime of a configured value.  Normally we talk about how operational values exist on their own and that, if one wants to override/extend them (e.g., associate a certificate to the private key created by the manufacturer), configuration would overlay the operational values.  By extension, if the configuration is removed, the operational values go back to their original state (i.e., existing on their own).   Here we're saying that, if the configuration (for the parent node) is removed, the operational values are removed as well.

Note that this statement was added because Juergen asked about how hidden keys could be removed/replaced.   We iterated towards not wanting to support the "replace" case, and this seemed like an easy way to handle the "remove" case.  Another way to do this would be via another action such as 'remove-hidden-key'.   What do you think would be best?

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Apr 2019 11:07:26 -0700

> action?   Will the action support all error-options of edit-config,

Strongly agree with Martin.
This issue of "server-generated config" has been around from the start.
NMDA was supposed to solve it. (It didn't).
There seems to be a need for standardized mechanisms to tell the
server how to magically instantiate data in <intended> that does not appear
in <running>.

The solution should be consistent and not ad-hoc.
This is a similar problem to config templates (which also lack any standard
solution).

Andy