Re: [netconf] latest update to crypto-types and keystore drafts

Balázs Kovács <balazs.kovacs@ericsson.com> Wed, 07 August 2019 08:51 UTC

Return-Path: <balazs.kovacs@ericsson.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 B8E4B120303 for <netconf@ietfa.amsl.com>; Wed, 7 Aug 2019 01:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 bYyxD6-5D-wY for <netconf@ietfa.amsl.com>; Wed, 7 Aug 2019 01:51:02 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70042.outbound.protection.outlook.com [40.107.7.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41670120285 for <netconf@ietf.org>; Wed, 7 Aug 2019 01:51:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YsXbThNgxWW/jUBzMlk0YTPH9sguKTx9sPfljsBTjcuyIdnBl6kIvPcSCp/Q2SGfdEXMtlpq+pn4x9CAIJt/tlBA2bay15/0QczPvqg2BXdl1UHV2mrzyEwsaIhEZSRENZvJvjnM/oCch4P+RfrpyT1RpbT5kGz7hMP2QnDRPjZZ17Z/1y6tK2OJRyI8WhR5azdCSrLxM5nsUWooQk4u68JjnhX67NxVzr5INxDNMDXfOA+nKaBREEBmNQWcnoNgWH7LSzzNxxTQa/ik4QxHb1IWB1yVF2nUlhHOuvdNjyT0eiRU85zjyoujD74AQMSvMUKYE+aCmAK8hxLrnFkxbw==
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=edHlgNAajMS+11QoD5Z8cZq4F/eU/dZij4wVFTwG5No=; b=REI9CDgR8BhPAiZIvcwb27TTNqOgHw+VsrzrEE8WKppq+MSM5CWDfwMLL4FNPrlILTI7ZID5NfY2utzSz8rT7CEDKLM5VjrUAfCYtrVhrRoqMEJwdamURm31g1eiYjyzSOGuDcHaqxH0M5oaVxqPIn8M2YhpIVUlCPpN1Ip4WJT1srZUl/kYMdmmI4E5sEfO6OF496sKvBrmrzqjkHW75b/XLgqx1kvVI1CkZnEgS63u2cjmU7INy8zUGehkf0YN7aIO8y8GLyDrD/FuZQX0qqtywMpfxYxAp+0txwotXbCt831a+USuRW73dCyme4LkTR50IpvS4kYFPjq7fik+4w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=edHlgNAajMS+11QoD5Z8cZq4F/eU/dZij4wVFTwG5No=; b=pVO0f/k/88UiqEKnTe7aOSFCoHMgqKTaqi4o+Q7k3HR7x4qTEZV+IKnCBBrTrHw9gip3ofwpI6c3ZgRRXlcnWyKQB7TecTKYR902AyM3UU3Sbq9PNlbaoPkWUxMmxfrNIFG3rHPhy82HaOREDJWdzftk2wl+h7zU6IxKx8cJQ0I=
Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB3920.eurprd07.prod.outlook.com (52.134.27.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.8; Wed, 7 Aug 2019 08:50:59 +0000
Received: from VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::4d62:fa38:f8a5:9299]) by VI1PR07MB4735.eurprd07.prod.outlook.com ([fe80::4d62:fa38:f8a5:9299%6]) with mapi id 15.20.2157.015; Wed, 7 Aug 2019 08:50:59 +0000
From: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= <balazs.kovacs@ericsson.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] latest update to crypto-types and keystore drafts
Thread-Index: AdUuSuzipKZ4tapKQ5qFcPhBDiZorQC3hTeABgDDVnAAGCnzgAB1K0EwABcsygAAGX6kcAAR0QQAACRBMpA=
Date: Wed, 7 Aug 2019 08:50:59 +0000
Message-ID: <VI1PR07MB47350F511BFF531411B76EC483D40@VI1PR07MB4735.eurprd07.prod.outlook.com>
References: <B8F9A780D330094D99AF023C5877DABAA49BA5A2@nkgeml513-mbx.china.huawei.com> <0100016bb4e4e11b-6cbb1c43-dea2-4c3f-a908-4a9ecfc69589-000000@email.amazonses.com> <VI1PR07MB4735C489562D237D5A72B24383D90@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016c54bba638-1b5714c0-bd81-473a-b6f7-71f5ab0033ba-000000@email.amazonses.com> <VI1PR07MB4735AE58A2FC2778EE03DD7E83DA0@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016c631aac91-86a67985-7e50-47ef-924d-8477383fd479-000000@email.amazonses.com> <VI1PR07MB4735A5E44BC4ED30BC4D696D83D50@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016c678a0e03-1e8334ab-4af3-426b-b0fa-73988d324a46-000000@email.amazonses.com>
In-Reply-To: <0100016c678a0e03-1e8334ab-4af3-426b-b0fa-73988d324a46-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com;
x-originating-ip: [89.135.192.225]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a91ec0e9-c769-4904-4fec-08d71b145ea9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR07MB3920;
x-ms-traffictypediagnostic: VI1PR07MB3920:
x-microsoft-antispam-prvs: <VI1PR07MB39206062A8B4B2C989A6FF6A83D40@VI1PR07MB3920.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01221E3973
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(39860400002)(396003)(376002)(189003)(199004)(86362001)(26005)(446003)(256004)(476003)(2906002)(71190400001)(74316002)(7736002)(66574012)(11346002)(14444005)(71200400001)(102836004)(33656002)(186003)(76176011)(316002)(6506007)(85202003)(7110500001)(53546011)(99286004)(7696005)(486006)(25786009)(4326008)(85182001)(76116006)(3846002)(52536014)(790700001)(229853002)(6116002)(64756008)(54896002)(9326002)(66556008)(81166006)(6306002)(236005)(9686003)(6436002)(66476007)(8936002)(55016002)(53936002)(478600001)(2420400007)(66066001)(14454004)(66946007)(66446008)(81156014)(6246003)(68736007)(5660300002)(15650500001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3920; H:VI1PR07MB4735.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 7d85UiahtLR+a3lbaII6GepCSpgRAD/VeclRUG27IWYLCswbB9Wxizy4DCk6Qe8NXU/xs+BFAvX/pnQkWtaf8IMAUgQycE9im8UU9xIi6Scsjfcy3HkrDyiE0IQLuDmRsHd0OUK5/qGsuk5mmyxfyDQA+brITSB0OIYugv3OzQAhXmr3SgZ04zpRcfFR+/gvNClCJLVq7HiGNOzVkoJZXfyLhfm0ldptuX+FQkDDA+qZJP1gv7/w15X9z4/Rm7R5z5QWE74c0hePQHVQ1lRMQ64e/pyfcq7mMLFR8ESXiZCawg4lRE2p9Pquge/F9yAtDPS27NCSOrecL/F0nlH0fmMDKX0NnH+NX/YGV9UEE4gl2MQWhvZK+bY0n5X5O1a9Z5rMZSuJ5pJ66pgPJqY66c77ftGJVWeTDAUrgPdz1wE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB47350F511BFF531411B76EC483D40VI1PR07MB4735eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a91ec0e9-c769-4904-4fec-08d71b145ea9
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 08:50:59.6635 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: frGzS+h9zUHlsDQsopw4KYnzeBZMZmkLHyyA8gNC2k3j3BJRsB8QISnAUnDMSlav7bPfwSUe7RThSLcHoXcr/mJw6w3uVDkLi0K+0vFh8j4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3920
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/HMYyhtZuXYiZkTz7KkR3F_ET0pE>
Subject: Re: [netconf] latest update to crypto-types and keystore drafts
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, 07 Aug 2019 08:51:06 -0000

Hi Kent,

Yes, so I just wanted to hint and also to get your agreement that there’s nothing enforcing that the client will store the operator key--which you used as a means of migration—in encrypted form. I do not want any change to the model in this matter, I think it is fair enough saying encryption in this case is up to the client.

Br,
Balazs

From: Kent Watsen <kent+ietf@watsen.net>;
Sent: Tuesday, August 6, 2019 5:27 PM
To: Balázs Kovács <balazs.kovacs@ericsson.com>;
Cc: netconf@ietf.org
Subject: Re: [netconf] latest update to crypto-types and keystore drafts

Hi Balazs,

I'm unclear if there is a request for a change of any sort here.   One thing that you may be hinting at is that, while the operator can install an operator key, there is no current mechanism to enforce that keys are encrypted with it, or even at all.

I'm currently unsure if there should be a knob/feature for this.  Perhaps servers should just trust the clients?  Most clients will be wrapped inside a controller/NMS app, and thus may restrict/enforce as needed via their interfaces to the human-operators.  Would this be good enough?

Kent



On Aug 6, 2019, at 3:11 AM, Balázs Kovács <balazs.kovacs@ericsson.com<mailto:balazs.kovacs@ericsson.com>> wrote:

Hi Kent,

Yes, sorry. This addition of symmetric-key is still to new to me. I meant the equivalent of clear and NACM protected key under symmetric keys. Which is just called ‘key’ in draft-ietf-netconf-keystore-12.

The reasons could be: the TPM or equivalent key may not exist or may not be present in keystore (which are roughly the same); or since the encryption of the operator-key is all up to the client, the client may just not implement encryption with the TPM or equivalent hidden public key as the client does not see extra security gains with that (the operator-key was created outside anyhow so it is already known by the client).

Br,
Balazs

From: Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Sent: Monday, August 5, 2019 8:46 PM
To: Balázs Kovács <balazs.kovacs@ericsson.com<mailto:balazs.kovacs@ericsson.com>>
Cc: netconf@ietf.org<mailto:netconf@ietf.org>
Subject: Re: [netconf] latest update to crypto-types and keystore drafts





On Aug 5, 2019, at 3:58 AM, Balázs Kovács <balazs.kovacs@ericsson.com<mailto:balazs.kovacs@ericsson.com>> wrote:

Hi Kent,

Yes, it makes.

I assume the “secret” symmetric key could be just equally configured as normal private-key since the key is coming from outside, depending on the taste of the client if it is just a NACM protected normal private-key or an encrypted key.

Since a symmetric key have "secret" value more so than "private" value, if we replace "private-key" with "secret-key" above, then yes, I agree.  Stated more plainly, a platform that doesn't have a TPM (or equivalent) protected asymmetric key, could instead protect the operator's symmetric key using NACM (i.e., only the crypto-officer/ restore-session can access it).  Is this what you mean?





Br,
Balazs


Kent