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

Kent Watsen <kent+ietf@watsen.net> Fri, 02 August 2019 23:48 UTC

Return-Path: <0100016c54bba638-1b5714c0-bd81-473a-b6f7-71f5ab0033ba-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 5F9E212004F for <netconf@ietfa.amsl.com>; Fri, 2 Aug 2019 16:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kDmnkXcqL-_r for <netconf@ietfa.amsl.com>; Fri, 2 Aug 2019 16:48:01 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18FC12002F for <netconf@ietf.org>; Fri, 2 Aug 2019 16:48:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1564789679; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=2YHi7Sgu8IVghbbHhWur2Huidb56r1RQrK3hFQ5nCVs=; b=XBqloAJ3soChilHp6TDWIVSa3zNalzjIlHnpdfOgP0s5XCQjq7ReP0L2GM6GTQu1 Kn5wDz9yUhTNjtPmP/f6kk4J8B3kTyAxNYwm+JIxLk56eOFkCjR16ZbGfzgM2qYPUbs inHEIWY7JNI+TCfpHpFPsEmicNgeW0zbtHp/TDoQ=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016c54bba638-1b5714c0-bd81-473a-b6f7-71f5ab0033ba-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_26AA6899-58FD-491C-B7FA-1C70A51F02FC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 2 Aug 2019 23:47:59 +0000
In-Reply-To: <VI1PR07MB4735C489562D237D5A72B24383D90@VI1PR07MB4735.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= <balazs.kovacs@ericsson.com>
References: <B8F9A780D330094D99AF023C5877DABAA49BA5A2@nkgeml513-mbx.china.huawei.com> <0100016bb4e4e11b-6cbb1c43-dea2-4c3f-a908-4a9ecfc69589-000000@email.amazonses.com> <VI1PR07MB4735C489562D237D5A72B24383D90@VI1PR07MB4735.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.08.02-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/pn0LucnWx3Xz0rfBRqB31BVg-Bk>
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: Fri, 02 Aug 2019 23:48:03 -0000

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