Subject: [netconf] Comments on draft-ietf-netconf-keystore v17

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Jun 2020 20:42:02 +0000

Hi Kent,

This is a well written document, and I do support progression.  I do have
some comments/questions...

(1) Section 1: You say:
   Special consideration has been given for systems that have
   cryptographic hardware, such as a Trusted Protection Module (TPM).
   These systems are unique in that the cryptographic hardware hides the
   secret key values.  To support such hardware, symmetric keys may have
   the value "hidden-key" and asymmetric keys may have the value
   "hidden-private-key".  While how such keys are created or destroyed
   is outside the scope of this document, the Keystore can contain
   entries for such keys, enabling them to be referenced by other
   configuration elements.

Question: Internally there might be several keystores on a router.  An
example is that there could be a TPMs for each different line card on a
router.  How is this YANG model about to expose which keys are associated
with specific TPMs?   E.g.: where in the model would you recommend such
augmentations to the grouping statements be made?

(2) This is likely a minor question:   I have seen a need for
"local-or-keystore-public-key-grouping" rather than
"local-or-keystore-asymmetric-key-grouping".  The only reason for the need
is that the private-key is never accessible (TPM again), and the private key
entries of the YANG model are never used.   Is there a reason why you didn't
have "local-or-keystore-public-key-grouping" beyond what could be perceived
as redundancy?

(3) Section 5:3 You Say:
   It was noted that, in this case, the second server would be
   unable to decrypt any of the keys encrypted by the first server.

Question: It is possible for the first server to encrypt a keystore using
the public key of the second server so that only the private key of the
second server would have access to these keys.  How do you see this option
playing in the migration process?

Thanks,
Eric

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Jun 2020 16:17:33 +0000

Hi Erik,

Thank you for your comments.

Please see below for more.

> augmentations to the grouping statements be made?

I have a few responses.

1) Already the draft “supports” the existence of a multiplicity of keystores.  Please refer to the exchange I had with Juergen on this thread regarding how my personal project does just this by a) NOT *implementing* "ietf-keystore” and b) NOT enabling either the “keystore-supported” or “local-definitions-supported” features, while c) augmenting in new leafref definitions into the “local-or-keystore” choice statements pointing to my application-specific instances as needed.   All this to say that it’s possible.

2) That said, for the use-case you described, I’m unsure if I would recommend going down that path, as the “keystore” can be thought of as an abstraction whereby it doesn’t matter if there are zero or many underlying keystores feeding into it.  How would clients care?  For the most part, the “builtin” keys and certs (e.g., IDevID) are read-only, with only the ability for the end-user to associate an LDevID for a builtin key being a quasi read-write scenario, but even then it seems trivial for the OS to figure out how to do the right thing, assuming there is a multiplicity of underlying TPMs.

Perhaps your question more regards the case of defining new (not builtin) TPM-protected keys whereby specifying the particular TPM that generates/protects the key is important.  As the quoted text above says, how such keys are created or destroyed is outside the scope of the document (so custom API can be used), but then I’d still expect that such keys to be presented in the one-and-only keystore without any designation to which TPM they resided in.

Reflecting back to when we were trying to define the so called “key-gen” RPCs (e.g., generate-asymmetric-key), the idea was to 1) allow the system to generate a “hidden” (aka TPM-protected key) and then, as a separate step 2) configure the generated key into the keystore whereby, if “hidden”, the system would be able to figure that out and do the right thing.  So it seems that the “custom API” mentioned above might’ve been implemented as an augmentation to said RPCs…

What’s the takeaway?  Perhaps this or something else?

OLD

   It is not required that a system has an operating system level
   Keystore utility to implement this module.

NEW

   It is not required that a system has an operating system level
   keystore utility, with or without HSM backing, to implement
   this module.  It is also possible that a system implementing
   the module to possess a multiplicity of operating system level
   Keystore utilities and/or a multiplicity of HSMs.

> have "local-or-keystore-public-key-grouping" beyond what could be perceived

That’s because public-keys alone are a Truststore thing (not a Keystore thing).  Looking at the "trust-anchors" draft you will find a “local-or-truststore-public-keys-grouping” grouping…is this what you’re looking for?

> playing in the migration process?

This is, in effect, exactly what the 2nd paragraph in that section describes:

   If the first
   server is still accessible, it may be possible to ask it to encrypt
   the key using the second server's root key.

But note the following sentence says:

   That said, a common
   scenario for needing to migrate configuration to another server is
   because the first server is no longer available.

Does this answer your question?

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 24 Jun 2020 20:07:19 +0000

Hi Kent,

From: Kent Watsen, June 24, 2020 12:18 PM

Hi Erik,

 

(1) Section 1: You say:

I have a few responses.

OLD

NEW

<eric> I certainly understand where you are trying to go better now.  And the second sentence in your NEW gets to my point.   So no further question on this one.

<eric>  Ahh yes.   I should have checked this other draft.  Question resolved.

(3) Section 5:3 You Say:

   If the first

   That said, a common

<eric> It does answer the question.   As you later point out: "How this is achieved may vary".   Rather than a using the organization's crypto officer (per later in the paragraph) I prefer having a shared key negotiated between servers.  Sealing can then be used for the replication of information between servers.   

But this isn't a draft about how to maintain redundancy in the keystore.  So I don't think any text changes are needed.

Eric

Eric

Kent // contributor

Thanks,
Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jun 2020 22:30:39 +0200

> 1) Already the draft “supports” the existence of a multiplicity of keystores.  Please refer to the exchange I had with Juergen on this thread regarding how my personal project does just this by a)…

True for some definition of "supports".

If the requirement is that we need to support multiple keystores, then
the container keystore should be turned into a list keystore. If the
requirement is to support multiple keystores located at various places
in the schema tree, well, then we likely can't do this properly with
plain YANG 1.1, but possibly with schema mount.

/js

PS: My definition of "supports" would imply interoperability. The
    current approach of "there is a grouping and if you tweak it
    enough it can give you multiple keystores" is not interoperable
    unless we standardize the tweaks.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>