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

Kent Watsen <kent+ietf@watsen.net> Tue, 18 June 2019 02:45 UTC

Return-Path: <0100016b68794a39-0d934910-4b4b-4801-8d56-27f678081e93-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 67EE7120203 for <netconf@ietfa.amsl.com>; Mon, 17 Jun 2019 19:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ASkTi73mE3NG for <netconf@ietfa.amsl.com>; Mon, 17 Jun 2019 19:45:09 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449D412003F for <netconf@ietf.org>; Mon, 17 Jun 2019 19:45:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1560825907; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=N/PSONSaZQuV5MFTQY2dc91HmShCui/r3m1HANRhRuw=; b=eLm1CTU0tZPLBbNhoIN63PmF4DWawZa3J9S5mLhX2e58Tyy5bJkjzFGW6YaJLva6 L+ITQcaInCzhu/n8LA3BR8ZbnEV9nI13cWW+6mWAtVirwSFypIywdbURmwrx5OZ688N z9YprZM8KFYzBRhudpM8t/J0PT1QjqNNCORMuTAM=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3EA59D93-D597-4FC0-BD9F-3EC07D0F7D43"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <0100016b68794a39-0d934910-4b4b-4801-8d56-27f678081e93-000000@email.amazonses.com>
Date: Tue, 18 Jun 2019 02:45:07 +0000
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.06.18-
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/omGJb3SBxRMnFASssI2OOC0GbcA>
Subject: [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: Tue, 18 Jun 2019 02:45:13 -0000

I started off trying to create a variation of "#2" but, as got into it, I realized that *encrypting* the keys would solve most problems.  Note that we really don't want "hidden" keys at all, as them not being part of configuration causes backup/restore problems.  What we want are values that can be treated like config, but are non-sensical without the decryption key.  Values MAY be encrypted using a manufacturer-generated key (which locks the value to the device), or a key generated by a *privileged* admin, which opens up the possibility for the key to float between devices.  

Specifically, imagine the following:

1) devices are shipped from manufacturer with a hidden asymmetric key in <operational>

Post-SZTP Onboarding:
2) privileged admin copies manufacturer generated key from <operational> to <running>
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.

Device Swap:
4) if replacing a device, load previous configuration.  Since all keys should be encrypted to the same symmetric key, it should load without error.  [note: one issue here with the secret symmetric key itself being loaded again, but since it was encrypted using to old device's manufacturer generated asymmetric key, the logic should be able to handle it.]

5) whenever a regular admin wishes to use a new key, they call the generate-symmetric-key or generate-asymmetric-key RPC, requesting the device to generate a key for them, encrypting the result using the secret organization key.  
6) The RPC output returns the key value (encrypted).
7) The regular admin uses e.g., <edit-config> to store the key into <running>.

Use cases: 
  0: normal (just NACM-protected) keys:  supported.
  1: manufacturer-generated permanently hidden keys: supported.
  2: device-generated keys: supported.
  3: device-generated keys in config: supported
  4: permanently hidden keys: not recommended nor directly
     supported, but one could always encrypt a key with the
     device's public key, thus generating a key that only the
     device can decrypt, and hence effectively permenently

Please let me know soon if you object to any aspect of this or, better, support it, as I need to update the remaining drafts to reflect these changes at some point soon.

Below are the change log entries.


   o  Removed the 'generate-key and 'hidden-key' features.

   o  Added grouping symmetric-key-grouping

   o  Modified 'asymmetric-key-pair-grouping' to have a 'choice'
      statement for the keystone module to augment into, as well as
      replacing the 'union' with leafs (having different NACM settings.

   o Diffs: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-08 <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-08>


   o  Replaced typedef asymmetric-key-certificate-ref with grouping

   o  Added feature feature 'key-generation'.

   o  Cloned groupings symmetric-key-grouping, asymmetric-key-pair-
      grouping, asymmetric-key-pair-with-cert-grouping, and asymmetric-
      key-pair-with-certs-grouping from crypto-keys, augmenting into
      each new case statements for values that have been encrypted by
      other keys in the keystore.  Refactored keystore model to use
      these groupings.

   o  Added new 'symmetric-keys' lists, as a sibling to the existing
      'asymmetric-keys' list.

   o  Added RPCs (not actions) 'generate-symmetric-key' and 'generate-
      asymmetric-key' to *return* a (potentially encrypted) key.

   o  Diffs: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-11 <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-11>

Kent // contributor