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

[Roman Danyliw <[e-mail]>]

Hi Kent!

Thanks for checking.  You are observing “user error” on my part.  I forgot to clear the DISCUSS text in the interface when adding my new COMMENT text, and I had to reissue my ballot.  The Datatracker correctly reflects my COMMENT-only position.

Roman

From: iesg <[e-mail]> On Behalf Of Kent Watsen
Sent: Sunday, March 10, 2024 4:58 PM
To: Roman Danyliw <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Qin Wu <[e-mail]>; Mahesh Jethanandani <[e-mail]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-netconf-keystore-34: (with DISCUSS and COMMENT)

Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe.

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]<mailto:[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