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

[Kent Watsen <[e-mail]>]

Hi Roman,

Thank you for your valuable comments.
Please find responses below.

One generally comment.  Many times it is unclear to be if you’re asking a question is your way of saying “please update the text to answer this question.”   Below I’m mostly just answering your question, without updating text, unless specifically stated.

Kent


> On Jan 29, 2024, at 6:08 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> 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.  

Indeed, that is true.  This section ("Encrypting Keys in Configuration") was written
because WG members were confused about how built-in keys  [see Section 3, 
"Support for Built-in Keys”] could be used to safeguard secrets.


> The introduction of this section says it applies to
> backup and restore.  

Backup/restore is the most-impactful interaction, the the section as a whole applies
to individual operations as well (i.e., configuring a single key)


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

Use of said API would be an example of configuring a single key, more so than
restoring of keys.

That said, please see https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-29#section-3.2
and also the "generate-public-key” RPC in the two refs docs:
	SSH: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-34#section-2.1.3
	TLS: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-34#section-2.1.4

Note that both "generate-public-key” RPCs can generate a “hidden” key or an encrypted 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?

Yes, YANG-driven protocols such as NETCONF/RESTCONF are accessible over a network.

It would be a decision for the server’s implementation as to also define, e.g., a CLI command, that could be invoked locally.

By controls, I assume you mean “authorization”.  Currently, neither of the "generate-public-key” RPCs have an NACM (RFC 8341) flag that would lead to a need for a client to be granted explicit permission to invoke the RPC.  The reasoning being that RPC primarily returns an output value (not set config) and a separate protocol operations (e.g., <edit-config>) would be needed to configure the key.

That said, that statement isn’t true when a hidden key is generated (hence the word “primarily” in the sentence above).  So perhaps it becomes necessary to put a “nam:default-deny-all” statement on the RPCs?

Actually, I just noticed a bug (whoops) in the YANG, that being that the RPC neither has an input-param to name the hidden key or an output-param indicating what generated-name to server gave the key.   Do you have any opinion as to if an input- or output- parameter should be used?


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

The term “server” is always used to refer to a, e.g., NETCONF, RESTCONF, or possibly CORECONF endpoint.

I can’t tell, are you asking for a text change here?


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

I just made this text update:
	s/implementations/Server implementations/


> ** 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?

Cleartext values aside, the server’s “security boundary” could be defined at the API-level, with no local access possible (e.g., no SSH into the box).  In such cases, one could argue that it doesn’t matter if keystore contents are encrypted when persisted to disk.   Of course, this isn’t recommended, I’m just trying to answer your question.  Please let me know if there is a text-edit you’re hoping for.




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

I agree the text waffles.
Are you asking for this?

OLD:  A MK is commonly a globally-unique built-in (see Section 3) asymmetric key.
NEW: A MK is a built-in (see Section 3) asymmetric key.


Thanks again,
Kent