[netconf] Roman Danyliw's Discuss on draft-ietf-netconf-keystore-30: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-netconf-keystore-30: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.  This section seems to define a workflow and mandatory server
capabilities above and beyond what is typically done by a RESTCONF/NETCONF
using a YANG module.  The introduction of this section says it applies to
backup and restore.  I’m having some trouble a few of the details.

Section 4.1, “If a KEK is a symmetric key, then the server MUST provide an API
for administrators to encrypt other keys without needing to know the symmetric
key's value.”

-- When in the backup and restore process is the administrator using this API
and what is the relationship between it’s use and the YANG module?  I observe
that the API in question isn’t labeled (in a way I recognized) in the workflow
diagram in Section 4.3.  Perhaps the administrator is constructing a YANG-based
configuration by hand and using this API to encrypt a key?

-- Is the expectation that this API is accessible over the network?  Can the
admin only invoke it locally?  Are there any controls expected to govern who
gets to invoke this mandatory API?

-- Is the “server” here the NETCONF/RESTCONF server?  Does it have to be?  I
ask because this text says, “the server”.  However, Section 4.2 allows for
generation+encryption “outside of the server”

Section 4.2, “Implementations SHOULD provide an API that simultaneously
generates and encrypts a key (symmetric or asymmetric) using a KEK.

-- (related to the above) Implementations of what?  Is this normative guidance
for NETCONF/RESTCONF server now provide additional functionality?

** Section 5.1.
  In order to satisfy the expectations of a "keystore", it is
  RECOMMENDED that implementations ensure that the keystore contents
  are encrypted when persisted to non-volatile memory.

If this recommendation is NOT followed how would this expectation be satisfied.
 Wouldn’t ensuring that the keystore is encrypted be mandatory?  Especially if
cleartext passwords are used?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Sandra Murphy for the IETF LC SECDIR review and Magnus Nyström for
the early SECDIR review.

** Section 4.3, “A MK is commonly a globally-unique built-in (see Section 3)
asymmetric key.”

-- If the MK is not built-in, the text only suggests “commonly”, how are any of
the promised scalability properties realized?