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

[Kent Watsen <[e-mail]>]

Hi Roman,

Thank you for clearing your DISCUSS ballot on all 4 drafts.  Your response for three of the drafts contained no additional comments (and hence I won’t reply to them).  But, for the “keystore” draft, two responses came…  

The first response (below) had more DISCUSS comments.   The second response contained just one COMMENT, which was/is the same COMMENT contained below.

IDK if you changed your mind on the new DISCUSS comments but, in any case, they are good comments, so please find my responses below.

PS: I'll post updates to the drafts ASAP.   I may ask for special permission to post before the window opens again.  That said, I’m still hoping to hear back from Murray, to clear his DISCUSS positions, so that may cause a delay...

Kent // author




> On Mar 9, 2024, at 5:52 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netconf-keystore-34: 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.

Yes, this section is different.  But it answers one of the most asked questions.  I added this as the second paragraph to Section 4:

    The approach presented in this section is not normative.  This section
    answers how a configuration containing secrets that are encrypted by a
    built-in key (<xref target="built-ins"/>) can be backup'ed from one server
    and restored on a different server, when each server has unique master 
    keys.  The API defined by the "ietf-keystore" YANG module presented in 
    this document is sufficient to support the workflow described in this section.


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

My previous response leans into this a bit saying "The API defined by the
'ietf-keystore' YANG module presented in this document is sufficient…”.  But
For clarity, the sequence of steps might be:

	- Crypto officer generates a clear-text private key
		- both the “ssh-client-server” and the “tls-client-esrver”
		  drafts define a `generate-asymmetric-key-pair()` RPC
		  enabling this creation.
	- Crypto officer stores the clear-text private key in a safe
		- e.g., on a dedicated air-gapped laptop

	- Regular admin decides to bring Server1 online
		- Regular admin sends Server1’s MK pub-key to Crypto officer
	- Crypto officer encrypts the clear-text private key using Server1’s MK
		- using CMS’s “EnvelopedData” (per the “crypto-types” draft)
		- this is a local operation (no NETCONF or RESTCONF API used)
	- Crypto officer sends the encrypted private key to Regular admin
		- this is KEK1

	- Regular admin configures KEK1 on Server1
		- using the “keystore” API defined in this draft
	- Regular admin configures the rest of Server1’s config,
		- including other keys encrypted with KEK1
		- using a combination of standard NETCONF/RESTCONF
		  commands and the “keystore” API defined in this draft
	- Regular admin backups Server1’s configuration
		- using standard NETCONF/RESTCONF commands

	- Server1’s power supply shorts, frying the board, it’s dead.

	- Regular admin decides to bring Server2 online
		- Regular admin sends Server2’s MK pub-key to Crypto officer
	- Crypto officer encrypts the clear-text private key using Server2’s MK
		- using CMS’s “EnvelopedData” (per the “crypto-types” draft)
		- this is a local operation (no NETCONF or RESTCONF API used)
	- Crypto officer sends the encrypted private key to Regular admin
		- this is KEK2

	- Regular admin restores Server1’s configuration on Server2
		- using standard NETCONF/RESTCONF commands
		- but this doesn’t work since Server2 can’t decrypt KEK1
	- Regular admin configures KEK2 on Server2 (overwriting KEK1)
		- using the “keystore” API defined in this draft
		- now Server2 can decrypt KEK2 and the device works again

Makes sense?

Yes, “server” is always a NETCONF or RESTCONF server.  The “outside
the server” bit regards local operations that a Crypto Officer performs (e.g.,
using the OpenSSL API).


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


A couple small updates:

    OLD: Implementations SHOULD
    NEW: Implementations of servers implementing the "ietf-keystore” module SHOULD

I also added to the end of that paragraph this (hopefully helpful) forward-reference:

     Such API is defined in the "ietf-ssh-common" and the "ietf-tls-common" 
     YANG modules defined in <xref target="I-D.ietf-netconf-ssh-client-server"/>,
     and <xref target="I-D.ietf-netconf-tls-client-server"/>, respectively.



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

Good point.  I added these two paragraphs the the end of Section 5.1:

   The keystore contents may be encrypted either by encrypting 
   the contents individually (e.g., using the "encrypted” value
   formats) or, in case cleartext values are used (which is NOT
   RECOMMENDED per <xref section="3.5" target="I-D.ietf-netconf-crypto-types"/>),
   then, e.g., disk-level encryption may be used.

   If the keystore contents are not encrypted when persisted,
   then server implementations MUST ensure the persisted storage 
   is inaccessible.

Clearer?


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Sandra Murphy for the IETF LC SECDIR review and Magnus Nyström for
> the early SECDIR review.
> 
> Thanks for the explanation on the Section 4.* crytpo API.  I recommend adding
> clarifying language to the effect of the details and authorization model
> associated with this API is out of scope for this document.

I’m trying to understand this comment.  I even went back to my response I sent to you on Jan 31.  I don’t understand.   

Perhaps this comment is a hold-over from the misunderstanding expressed above regarding the needed API.  My impression is that you thought it was an API defined outside of this document when, in fact, it is the API defined by this document (in YANG) and, as such, subject to the authorizations given by the NACM layer.

With that misunderstanding resolved, do you see how I’m unsure how your comment applies?

On a side-note, I did update the "generate-asymmetric-key-pair" RPCs to return the location to where hidden keys are created.  This was the “bug” I reported finding in my Jan 31 email.


> Thanks for addressing my other DISCUSS and COMMENT feedback.


Thank you!
Kent