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

"Eric Voit (evoit)" <evoit@cisco.com> Wed, 24 June 2020 20:07 UTC

Return-Path: <evoit@cisco.com>
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 7E4963A11B5 for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 13:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DAoidzha; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=pK5d6zbT
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 5yAPWc_mPleV for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 13:07:23 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A4E3A11AD for <netconf@ietf.org>; Wed, 24 Jun 2020 13:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26998; q=dns/txt; s=iport; t=1593029242; x=1594238842; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Zmfs9BvxrgV0pncwABUurhrzgcir9rJCRneGrc3dVE8=; b=DAoidzhatnzlyFh/rL3n+APRoARn0nwbTbdnX7F3fuCdKCe3E1Btslgu fhZToO2KaxWW1WVMFWubITYfZUp4F5XnNnKXs1nVRhE/wF6vhTCF3exqP 9nTwsz2m6njE3okciU8tAWZeRQ1w6ytapRyBqFCJJyIkegwxlKeG9RSE0 4=;
X-Files: smime.p7s : 3975
IronPort-PHdr: 9a23:x9U/qBxJqcMcQIHXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5ZRWBt+pkkETEW8Pd5u4Xw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoLkFJA8v4IVvfvi764TsbAB6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0COBQAzsfNe/4ENJK1mHAEBAQEBAQcBARIBAQQEAQGCCoEjLyMuB28rLS8sCoQag0YDjUaYV4JSA1UEBwEBAQkDAQEtAgQBAYRHAoIVAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFcgEBAQEDEhEKEwEBNwEPAgEIFS0CAgIwJQEBBA4NBhSDBYF+TQMfDwGsRgKBOYhhdoEygwEBAQWFKRiCBwcJgTiBU4EUiDqBJQEdGoFBP4FUgk0+hCUaFYJ9M4ItpB2QTgqCWoQpglWSUYJxiSWFHogvhSCsWlWCVQIEAgQFAg4BAQWBaiKBVnAVgyRQFwINjh4MF4NOilZ0NwIGAQcBAQMJfI8+ATFfAQE
X-IronPort-AV: E=Sophos;i="5.75,276,1589241600"; d="p7s'?scan'208,217";a="531626314"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2020 20:07:21 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05OK7Lpq031506 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jun 2020 20:07:21 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 24 Jun 2020 15:07:21 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 24 Jun 2020 15:07:20 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 24 Jun 2020 16:07:20 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kj0m064LA5uQGgyOGRG2nV+L6DHcJVTWYFFfYpwTaxdBf2QI30ioBB268bP3RpUOLkeLGH8YPjQKeKecb6tGyN8jitN7TnePorocYA0Xb9Pt6P8ZzwOv6fZ74ilgjJXXcakno4fU+K7D3Q+qU64lm1Uk4NQ9nbXBgKN1IhBDk+RX1tS7Xrah0XdtWWlO9IQr+AuPhgPG9FIUWcDrAQwXDlTNP6Qhdi0MzKUCqEGTh5km4jBKvJronEzjvYrJHdrMMiic0aK0Mc8fCZNEZoKtNC8CSStsmLiMbbbF/2+U+ADu13XRt0zltnkcM8nY4wD14mrmrVxEO75boY7VJRAYig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SDQ5h877yuTv/CX2P9htOyt6u/aZfEa6NBTgHo7plKs=; b=ETnwRL64KYHFUXm5X8Ysgg9yI4jaE/teBamDvw1rPrVNEdVF/FRXvlR1YJv/hNC4i3gFsy7qH5HsHWvPjsMWG983pZGXdRJXNIB02U0q0JsTkOXjF3+a17OEy1zu7p61SgiKRYroRURWDopx7gFIPw/NMo09cXszwsofKAIUXqxnDmjrvVKsI5nASEMdYkW7dQmQJyz6X2qbJNiReYgFpkFuJ6WixN8IcCc8kp4Q/3zo2gAtbigfVr+d3UoTwHplIPPmb4AbvaePDZSS7twKMUozc3CvUyOK1hHMT53O1ysqBt9dyV5N1sr40rL6iQDhw3ESHqmJ6VNTgbrSurbZKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SDQ5h877yuTv/CX2P9htOyt6u/aZfEa6NBTgHo7plKs=; b=pK5d6zbTy3AcQ8RD0tBoPQxqFDWVUtHVZhDOSWlLh7+CkdjJdooIXg+GI/D+SfgOmAJYnwpy++x2TxdPVOEDJoNkcIi47V9ocLfhLg/V54yRFfik559/rR+TXQx3oCGEyAkFsyrDvBRpThEbc8oI5bakMdpFS0CK3vcTSfJqLbQ=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3027.namprd11.prod.outlook.com (2603:10b6:208:77::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Wed, 24 Jun 2020 20:07:19 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290%7]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 20:07:19 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Comments on draft-ietf-netconf-keystore v17
Thread-Index: AdZJi6eAeMmOZqZaQ3i6nM88A9zjLwAt0+6AAAZlSdA=
Date: Wed, 24 Jun 2020 20:07:19 +0000
Message-ID: <BL0PR11MB3122AC25FCF3F06ECC30C7A7A1950@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <BL0PR11MB31224C35E1100037780F7DE6A1940@BL0PR11MB3122.namprd11.prod.outlook.com> <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@email.amazonses.com>
In-Reply-To: <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.72]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d37e3a9a-15ca-4705-c1bd-08d8187a331d
x-ms-traffictypediagnostic: BL0PR11MB3027:
x-microsoft-antispam-prvs: <BL0PR11MB30275AE1BAA9DF6295253AC3A1950@BL0PR11MB3027.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0444EB1997
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cpgE9XArfxUnirW8OMKHkwcIULByBXAWqsqKEH9mBtnpqjv2WgpWLiNiQFGyLb+oJgWX97bgEkIrPqQv98l4Pk+mYnZzWZLBfI5fzS7cyQfawJRizVa63oNNmfc8bOASLR0jpqka0Z8Clabfcdd38TgVtilBs8lTTtniG68E6iktQPDoHXEwpVNSjodMmLoMEdWBB+73uhif/WYTCzhdh8FYDU2x4q4m/meiKj3uaLs+PHMfSEv4EI9iZkFdBLROO0z+RszC1umgMqIOoxpSrhLB/mAxfwYvyMOJiokqjieL1NJTlBAlWZWCNa3gfkeD6uWMEk37+4HExQVs7OL3Ug==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(396003)(376002)(346002)(7696005)(9326002)(316002)(26005)(71200400001)(186003)(6506007)(2906002)(55016002)(9686003)(83380400001)(478600001)(4326008)(8676002)(99936003)(66946007)(86362001)(76116006)(66574015)(8936002)(52536014)(64756008)(33656002)(66476007)(66616009)(66556008)(5660300002)(66446008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: MQG4Hzh3E0luotj85ytzA4EdsZq0X7j3b5/PfB8sL++wZ3Lhdi5OR7tfgP60jaR6NYGa5xlhh/QpOeud6fm8SrOAidiGt6DX4bjintEMT/GXtGgIXhLFi+ZlCSqLQi4ZGZLYONM0+nBLVIMjT2tb0eSNDAauWL7RbL/8uxUksGcYIitHi4prYRQIg0hoPPUJ+GSt1s+3g44dDgGl3sWy7+FU5IAYzJcPKXvatCUN0BsUw9pzmLmMWAelQPa2zJB86gkxkQ9KtaOpG4p7a1q58ZWC3q69n7rTlauqffbhe4EA+11CSokGgoccFkAVgCBWQEKLjlWiXt0zchRyCeOtuJWGuGhfTLsUJntiJjUs/u4AUfplt/yfRlk2xZH4f9UlOiQZ5u56YM5Nrdqz5W73NTkt538bjOOFaXNHgozS3v2VuzSp7VQsnGzIgc6YoEKnrx4PjzqE3t3SSrGG2Dzfta2AsxDKIzqLqoMu0C5t0f4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0430_01D64A3E.80A2F7C0"; micalg="SHA1"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d37e3a9a-15ca-4705-c1bd-08d8187a331d
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 20:07:19.4340 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mWeDTXPz9RFs1CPUWAVz2pOzCpZuD3Ys1YcmbZw+BihoBVJXADzhQDZCWRhhPZRL
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3027
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/RlgpS0v42absxUpB1_5wboTdZgU>
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 20:07:29 -0000

Hi Kent,

 

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



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.

 

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

 

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

 

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



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

 

<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