Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

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 {
          enum permanently-hidden {
            description
              "The private key is inaccessible due to being
               protected by the system (e.g., a cryptographic
               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 <[e-mail]> wrote:
> 
> Hi,
>  
> Is there a conclusion on this thread?
>  
> Alternatives I’ve seen:
>  
> ‘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
>                                                                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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Balázs Lengyel
> Sent: Friday, April 5, 2019 4:54 PM
> To: Martin Bjorklund <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> 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 <[e-mail]> <mailto:[e-mail]> wrote:
>  
> ----- Original Message -----
> From: "Martin Bjorklund" <[e-mail]> <mailto:[e-mail]>
> To: <[e-mail]> <mailto:[e-mail]>
> Cc: <[e-mail]> <mailto:[e-mail]>
> Sent: Thursday, April 04, 2019 6:46 PM
>  
> Juergen Schoenwaelder <[e-mail]> <mailto:[e-mail]> wrote:
> On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote:
>  
>  
> We have always said no, but the reasoning is unclear.  What are
> the
> 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.
>  
> 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.
>  
> 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.
>  
> Agreed!  BUT, then it should not be modelled as configuration, imo.
>  
> And the current model already handles this case with "hidden" keys.
>  
>  
>  
>  
> /martin
>  
>  
> This is security - it matters.
>  
> Tom Petch
>  
> So I don't think the reasoning is unclear at all.
>  
> /martin
>  
> _______________________________________________
> netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>  
>  
>  
> _______________________________________________
> netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>  
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: [phone]              email: [e-mail] <mailto:[e-mail]> 
> _______________________________________________
> netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>