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

Balázs Kovács <balazs.kovacs@ericsson.com> Mon, 05 August 2019 07:58 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 52FF912006F for <netconf@ietfa.amsl.com>; Mon, 5 Aug 2019 00:58:59 -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 30Kv-lOKtYgJ for <netconf@ietfa.amsl.com>; Mon, 5 Aug 2019 00:58:56 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40067.outbound.protection.outlook.com [40.107.4.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86E612001A for <netconf@ietf.org>; Mon, 5 Aug 2019 00:58:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NrHX7II1s5tNUzWOnemAp4qqOGFfPuagtQ5SsNxwk5AaVlEJi2vXLm2XKcGcHJVTVFByDDAaU307/kGoSIPjH8U/7o+qGqnhSDEOAIW7jWQTz5TSi/c2FvSCQziAx9E2kRmsFVHY71d8TOWR7kat8VP3hmYgDnv0Iiz4yBo2w/nKe51mDajoW26E9H253HZjaD7B8CSEnWF57Jh1R7K/rqCY07CFeItfL0K8IbRblGo6fTwFnHtDblyinviwSW2ILZW3M9uOe3U9UCeSeEt8WmaXm31nKVY+GibfMvRhZKf9cLVbTEaAKZFY2tDj3+s7TBo42u4WiXULkj3i32IgUg==
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=BhoozrwlG889Y0I40jJkwTqa5rHZtdlh17ADdk/3D3Y=; b=hf0y2rySUy/9m2Eh7JNmTDcJGZWimCjLj0d+5UVo/bB86/4Gf/sOqP4hAZJlYM49T0OZ4Jab7iQvmZOTNbWcfNr8Zl1OQqu+fLn6eHAPaERfzxlMqfLaOqNrBSiAbovEQtO3dw7c4N2PtSVbeiuGvCw3yTWiNiG0gYTsDv9nr3HOObZrIpoKfYoi2j8WPmYY0bO6z85MpUNb0mHisug63Xbi/4HeEc4ViCvw9/WMOsIq/wXC3no47RDIghCVOh9JZCKmKtagDkFcHmElGLW4k64LwECiFOkxweqL70vmsBVAfLfgroA93GcVp9dTXF7TqSQgl5e2o9KQR5e9vWVlVQ==
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=BhoozrwlG889Y0I40jJkwTqa5rHZtdlh17ADdk/3D3Y=; b=ZyQxDR4+ud3OHNwIQT9c1zIWUVWARKkzoSdz2lnQ2cDt8e+o7UZ/7gnpmq72h758U7/NLZCZi1hPpRgmx9IKNwtuYhL8HCNVacHgG8Wlui9ys42sgevRopxmVlucTHnlmcmGK7+dGpacNRJWOrRpe1vizwdvjN5/caK6hJF7IwA=
Received: from VI1PR07MB4735.eurprd07.prod.outlook.com (20.177.57.146) by VI1PR07MB6271.eurprd07.prod.outlook.com (10.186.160.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.8; Mon, 5 Aug 2019 07:58:53 +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.011; Mon, 5 Aug 2019 07:58:53 +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: AdUuSuzipKZ4tapKQ5qFcPhBDiZorQC3hTeABgDDVnAAGCnzgAB1K0Ew
Date: Mon, 5 Aug 2019 07:58:52 +0000
Message-ID: <VI1PR07MB4735AE58A2FC2778EE03DD7E83DA0@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>
In-Reply-To: <0100016c54bba638-1b5714c0-bd81-473a-b6f7-71f5ab0033ba-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: 5cb62e28-4c01-4b8e-e94e-08d7197ac22c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR07MB6271;
x-ms-traffictypediagnostic: VI1PR07MB6271:
x-microsoft-antispam-prvs: <VI1PR07MB6271902FFB04CEC6B1532A0583DA0@VI1PR07MB6271.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01208B1E18
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(396003)(376002)(346002)(189003)(199004)(66066001)(25786009)(71200400001)(229853002)(14444005)(71190400001)(256004)(8676002)(236005)(9686003)(54896002)(6306002)(4326008)(55016002)(2906002)(6436002)(81156014)(81166006)(85182001)(15650500001)(2420400007)(76116006)(66476007)(64756008)(66556008)(11346002)(446003)(476003)(52536014)(486006)(7110500001)(66946007)(66446008)(74316002)(26005)(6116002)(66574012)(790700001)(3846002)(316002)(7736002)(6246003)(14454004)(5660300002)(86362001)(33656002)(99286004)(102836004)(9326002)(186003)(7696005)(85202003)(68736007)(478600001)(53936002)(8936002)(6506007)(53546011)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB6271; 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: NC+7rBG3vGUJ7+QF3dz13KhedDi6NuqsiHuTjEG9vjhXRnCePZ/MILgzHXDjCvby8piX1tq7yuku8q36C5+JCiZkk4FgzQNHa7IDSJVs5oGKu+WSiwNRc0eyPPzYV78sKGEOuQSwhK83xOvJGfpbQLi1lps0e/JJaCRSlPlTRTtuxdstsVfwbw6I62jnYs0a4HytV+ueVSikT1pXVvYSn1stV6hPVEEHjSmnmFeD3loZgxLxizRCtJiaxXmwWHT3tQZGq89d8MNpMy2kI1AfPLwUztayhqD4SdMTgUWsTZv/RHOL4MZeKgc6peITgXA6JIEvxh0Q/2mGn1JX49cUbrvtVFAe9UUQNcfOEFGFqCF/1X8AsiP2SWYgbXgBFarom8+M5jEjovMCCj5qWqYmCXC9h7de9pEHm/UaE0U92Yc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB4735AE58A2FC2778EE03DD7E83DA0VI1PR07MB4735eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5cb62e28-4c01-4b8e-e94e-08d7197ac22c
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 07:58:52.9533 (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: 9zajYIXrojbqLaOqMNuTLjq4BY6bGwmlCW5p+PbyTyA/ZiiX7R0ZTn6VHanqQ1+yX/g6Qf0IaZ2DAhRXiOi1RthDsgKN6WulsWbm2c4A/x8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6271
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/SD6eGyaOpsAZoOE90XPAZAj8FiI>
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: Mon, 05 Aug 2019 07:58:59 -0000

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.

Br,
Balazs

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


Migrating configuration, including encrypted keys, from device-1 to device-2.

Preconditions:

    1) the client possesses a "secret" symmetric key
         - for this example, the key's clear-text value is known to the organization's
           "crypto officer", but it seems that it could as well be protected by an HSM.
         - this symmetric key value MAY be unique per device, region, or whatever
           boundary the organization chooses up to being globally shared by all
           devices.

    2) devices 1 & 2 each posses a unique asymmetric key that, e.g., may be
        associated with an secure device identity (e.g., IDevID)

+--------+           +----------+          +----------+
| client |           | device 1 |          | device 2 |
+--------+           +----------+          +----------+
    |                     |                     |
    | 1. get config       |                     |
    |-------------------->|                     |
    |                     |                     |
    | 2. scrub config     x                     |
    |-----------------+                         |
    |                 |                         |
    |<----------------+                         |
    |                                           |
    | 3. get tpm protected asymmetric key       |
    |------------------------------------------>|
    |                                           |
    | 4. encrypt operator's symmetric key       |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 5. stitch encrypted op key into cfg       |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 6. stitch additional info into cfg        |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 7. set config                             |
    |------------------------------------------>|
    |                                           |
    |                                           |


Steps:

1. get config

    - the client gets the full configuration from device-1
    - this config would contain an entry for an encrypted operator key
    - this config may also contain an entry for the tpm protected key

2. scrub config

    - remove the encrypted operator key
    - remove the tpm protected key, if present

3. get tpm protected asymmetric key

    - the client gets the tpm protected key from device-2
    - this key's "private-key" value would be hidden
    - only the algorithm and public-key values are present

4. encrypt operator's symmetric key

    - using device-2's public-key, encrypt the operator's "secret" symmetric key
    - this is a local operation, using any crypto library

5. stitch encrypted op key into cfg

    - put the new encrypted operator key into the config

6. stitch additional info into cfg

    - put other, presumably non-migratable info into the config
      (e.g., node-locked licenses, etc.)

7. set config
    - set the new config onto device-2

Done.  Makes sense?

Kent // contributor




On Aug 2, 2019, at 8:41 AM, Balázs Kovács <balazs.kovacs@ericsson.com<mailto:balazs.kovacs@ericsson.com>> wrote:

Hi,

One question regarding migratable keys. The conversation between Kent and Martin was concluded with this in the list:

“That said, the general recommendation, which would both be correct and avoid any potential failures, would be for the client to remove the device-specific and operator-wide keys first, leaving just the migratable keys in the config uploaded to the second device.”

I don’t see how migration is possible here. The migratable keys were generated on the first device and are encrypted with the operator key of the first device. Does the second device has a different operator key? If yes, the migrated encrypted keys cannot be decrypted by the second device.

Unless I misunderstand this statement (which I don’t see how to achieve in the model):

“3) privileged admin encrypts a well-known (secret to the organization) symmetric key using the public key from the manufacturer generated asymmetric key, and stores the result (i.e., <edit-config> into keystore.”

Does this well-known symmetric key mean that the symmetric key was generated externally thus its clear value must be configured to /ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/ct:private-key? How is the operator key configured in clear to the second device so that it gets encrypted with the hidden manufacturer key of the second device?

Br,
Balazs