Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore

Kent Watsen <kent+ietf@watsen.net> Thu, 13 August 2020 18:23 UTC

Return-Path: <01000173e90f9703-c3dcb1ba-0b0d-431c-b7db-93389b5dca37-000000@amazonses.watsen.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2118A3A1033; Thu, 13 Aug 2020 11:23: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_MSPIKE_H2=-0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is1VK2ii4dt5; Thu, 13 Aug 2020 11:23:01 -0700 (PDT)
Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4303A101C; Thu, 13 Aug 2020 11:23:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1597342980; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=yFtMULbagB0WSTyl/ot4VpF9c+E3D3mejRlmiUHFRQ8=; b=XNQjeq5VxqkBxL+LMrho/T0s7vGHIFFjrkOzbBID2th+bmgY7x+unyPzoimuQ+0h 84OjdlnhDhxD5RTXDCF3PqLZ8Qz5mIpw/rTFUzGyNR69Z+z9fgPIm4tGbw+Lz1/0t9I KHQ9mWzhe8CS3KrzTIsAPA0fjuY5UIUh7IbFF1Kg=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000173e90f9703-c3dcb1ba-0b0d-431c-b7db-93389b5dca37-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_25F0ED38-24EF-48CB-A63A-B17F427DAA99"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 13 Aug 2020 18:23:00 +0000
In-Reply-To: <4259FA7C-8A2F-4F3E-B998-CD870EE9E3C0@tislabs.com>
Cc: =?utf-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, draft-ietf-netconf-keystore@ietf.org, secdir@ietf.org
To: Sandra Murphy <sandy@tislabs.com>
References: <CADajj4ZQnWkjKdWpBgsB0oyX8_Kzj6HOL-Vkm=TrByBQMEJfPw@mail.gmail.com> <CADajj4bCTF5EeF6DZkCHpP0_GTnUYQtqa0OE3qf3Z5_AmKWfyA@mail.gmail.com> <CADajj4YxgdNXkWX7dLP0nBDWXLSKFa8M_KWWCPCgfCibYtWkAw@mail.gmail.com> <CADajj4Yw13QWbSqF_hd+P_fcNA4_YvdwqF=OgJ4pdS_1vrWphA@mail.gmail.com> <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com> <01000173db1fc8cc-e5530e7a-c300-4f8f-8068-0fbe7fd51926-000000@email.amazonses.com> <CADajj4Z+RwY48xewVnQ+Jd0CRHsr0U3G=ecgoWEAuRdwK1rm8A@mail.gmail.com> <01000173e318a0ab-ab85dee0-63dd-4477-9f3b-006c6ffbfcf1-000000@email.amazonses.com> <4259FA7C-8A2F-4F3E-B998-CD870EE9E3C0@tislabs.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.08.13-54.240.48.95
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/PQwTf-Q6MpynEY5qiZb5A59Qo6I>
Subject: Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2020 18:23:03 -0000

Hi Sandy,

>> On Aug 12, 2020, at 10:35 AM, Kent Watsen <kent+ietf@watsen.net> wrote:
>> 
>> I just want to confirm, did you read the new Section 4 (Encrypting Keys in Configuration) in the plain-text draft I attached in my previous response? 
> 
> Taking a look at -20, it looks like Section 4 is the only change (of substance).
> 
> I see that you removed the early paragraph that says the root key should be hidden but might be unhidden with careful access control.  Have you abandoned the idea of an unhidden root key (aka MEK)?

It has not been intentionally abandoned, for the simple reason that not all devices may support “hidden” keys and so access-control is all they can do.  Sadly, this is in fact what most systems do today.

While the "root key” was generally mapped to “MEK", the section containing the text you mention was more about a KEK.  Thus I made this tweak to my local copy:

OLD:
           In other deployments, an organization's crypto officer, possessing the
            KEK's cleartext value, configures the same KEK on the second server,
            presumably as a hidden key so that the cleartext value is not disclosed
            to regular administrators.

NEW:
           In other deployments, an organization's crypto officer, possessing the
           KEK's cleartext value, configures the same KEK on the second server,
           presumably as a hidden key or a key protected by access-control 
           (e.g., NACM's "default-deny-all), so that the cleartext value is not
           disclosed to regular administrators.


> The revisions have eliminated the "Given the long lifetime of built-in keys (see Section 3), built-in keys MUST be hidden.”  Did you intend to eliminate that?

Kind of.  I feel that this draft cannot be overly proscriptive. The closest new text follows with an enhancement that (I think) strikes the right balance (i.e. the “MUST” in the quoted text becomes —> "commonly…hidden”).  However, I tweaked the text a bit more to be even more like that from before:

OLD:
            A MEK is commonly a globally-unique built-in (see <xref target="built-ins"/>)
            asymmetric key for which the private key is hidden and the public key is
            contained in an identity certificate (e.g., IDevID).

NEW:
            A MEK is commonly a globally-unique built-in (see <xref target="built-ins"/>)
            asymmetric key for which the private key, due to its long lifetime, is hidden 
            (<relref section="2.1.4.4." target="I-D.ietf-netconf-crypto-types"/>) and the 
            public key is contained in an identity certificate (e.g., IDevID).



> Are MEK and KEK the only keys that can be used to encrypt other keys?  I thought the YANG model permitted using a reference to any keystore key in the encrypted-by field.

Correct.  In fact, the YANG model itself doesn’t know anything about MEKs or KEKs; it only has keys, which MAY be builtin and MAY be encrypted or hidden.  Effectively the model supports any key encrypting another key and, in that sense, any key can be a KEK.

Sections 3 and 4 attempt to highlight best/common practice (for those that might not know any better) without limiting possible variations (for those that think they do or otherwise are more adventurous).  ;)


Kent