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

Kent Watsen <kent+ietf@watsen.net> Wed, 24 June 2020 16:17 UTC

Return-Path: <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1257D3A0FFB for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 09:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN4wKzsCzPqg for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 09:17:35 -0700 (PDT)
Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339403A0FF9 for <netconf@ietf.org>; Wed, 24 Jun 2020 09:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593015454; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=7f1+H/Xec9Tic2T+DpgS3QOyf3M4vH4vAsvOl/CnMwE=; b=GSYYCsz7Zhjtm/dx8J7wgMjLRyhB6QiHbU+AxXzvspH8IKLm5O0gG9wGcIJYOiJg jIPbH+tzH4DlKQpNkDij/DeBhHYyD6z4LdD3Fb4Q+N//FXB/68yEDpWbTD9hkkatVW3 UZ/mZfLiUXSNNWLgsPIBWwlswMKtdYvxWXHtu7vI=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E2C9EA2C-17BA-4E4A-9193-DA1013414E80"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 24 Jun 2020 16:17:33 +0000
In-Reply-To: <BL0PR11MB31224C35E1100037780F7DE6A1940@BL0PR11MB3122.namprd11.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <BL0PR11MB31224C35E1100037780F7DE6A1940@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.24-54.240.48.92
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WU766fvV5Ez0HwmLt2n4OgOUlT8>
Subject: Re: [netconf] Comments on draft-ietf-netconf-keystore v17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 16:17:37 -0000

Hi Erik,

Thank you for your comments.

Please see below for more.


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

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.



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

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?


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

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



> 
> Thanks,
> Eric