Re: [netconf] ietf crypto types - permanently hidden

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

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 <[e-mail]> On Behalf Of Balázs Lengyel
Sent: Friday, April 5, 2019 4:54 PM
To: Martin Bjorklund <[e-mail]>; [e-mail]
Cc: [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







_______________________________________________

netconf mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/netconf



--

Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: [phone]              email: [e-mail]<mailto:[e-mail]>