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 ; 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 ; 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 ; 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 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: Cc: "netconf@ietf.org" To: =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= References: <0100016bb4e4e11b-6cbb1c43-dea2-4c3f-a908-4a9ecfc69589-000000@email.amazonses.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 23:48:03 -0000 --Apple-Mail=_26AA6899-58FD-491C-B7FA-1C70A51F02FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=20 "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=C3=A1zs Kov=C3=A1cs = wrote: >=20 > Hi, > =20 > One question regarding migratable keys. The conversation between Kent = and Martin was concluded with this in the list: > =20 > =E2=80=9CThat 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.=E2=80=9D > =20 > I don=E2=80=99t 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. > =20 > Unless I misunderstand this statement (which I don=E2=80=99t see how = to achieve in the model): > =20 > =E2=80=9C3) 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., = into keystore.=E2=80=9D > =20 > 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? > =20 > Br, > Balazs --Apple-Mail=_26AA6899-58FD-491C-B7FA-1C70A51F02FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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       |
    = |--------------------------------------+   =  |
    | =                     =                  |   =  |
  =   |<-------------------------------------+   =  |
    |   =                     =                     = |
<= /div>
  =   | 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=C3=A1zs Kov=C3=A1cs <balazs.kovacs@ericsson.com> wrote:

Hi,
 
One = question regarding migratable keys. The conversation between Kent and = Martin was concluded with this in the list:
 
=E2=80=9CTh= at 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.=E2=80=9D
 
I don=E2=80= =99t 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=E2=80=99t = see how to achieve in the model):
 
=E2=80=9C3) 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.=E2=80=9D
 
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

= --Apple-Mail=_26AA6899-58FD-491C-B7FA-1C70A51F02FC--