Re: [netconf] ietf crypto types - permanently hidden

Kent Watsen <kent+ietf@watsen.net> Tue, 07 May 2019 21:13 UTC

Return-Path: <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-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 9C8581202B1 for <netconf@ietfa.amsl.com>; Tue, 7 May 2019 14:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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, RCVD_IN_MSPIKE_H2=-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 zhf9lqIu4wRA for <netconf@ietfa.amsl.com>; Tue, 7 May 2019 14:13:46 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF64120170 for <netconf@ietf.org>; Tue, 7 May 2019 14:13:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1557263624; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LHfsrPdwBSD27WwdKt2mW2BUm5BlFsPI3oDQjsnsY0E=; b=J+G/cjO/ojIlafaEkJ3y+KMdR/zvpuVW7YxUeyo5Q/8lqRsvDJLszDowxLjOCXrg mPgbjMD3vSL2lHRcOFaYnvd5bZOKTnuWjSM7SowkkFWvkXSMrX2sdTLxzl7i0eJjN3t qogyoB65ZHZDq+w4I+++rm4ZOMoy1z5s0P0ZzRGo=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016a942528d9-f65afd2a-2cc7-451d-93d8-788495f6a13a-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0A1DEEFB-F337-447D-8C43-0AF892693851"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 07 May 2019 21:13:44 +0000
In-Reply-To: <20190507.141926.1879619200930898148.mbj@tail-f.com>
Cc: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
To: Martin Bjorklund <mbj@tail-f.com>
References: <0100016a7e7a9e54-d4987061-96d8-49f3-a2bf-36b98851b3a3-000000@email.amazonses.com> <0100016a7e822689-e6fdbdbe-ba84-43e1-aefe-47196fe692e3-000000@email.amazonses.com> <e6930b6e52a642bda9f1bd76731ce9c3@XCH-RCD-007.cisco.com> <20190507.141926.1879619200930898148.mbj@tail-f.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.07-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc>
Subject: Re: [netconf] ietf crypto types - permanently hidden
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, 07 May 2019 21:13:54 -0000


>> The problem that I have with <generate-key> generating configuration
>> directly in <running> is that <running> on the device is now different
>> from what the management system thinks should be in <running> on the
>> device.
>> 
>> I.e. it breaks the architectural simplicity that it is only the client
>> that controls what goes into in <running>

I'm confused.  At least it seems that, regardless if the client uses <edit-config> or <generate-key>, the client is performing the operation and can be fully aware of what it is <running>.  For other clients, presumable they receive a yang-push notification alerting them to the update to <running>.

Before I thought the objection regarded non-compliance to the document model, but that's not true in that, once the configuration is set (via an action), it becomes part of the document, even if nacm:default-deny-all.

Now I'm unclear what the objection is.  Martin has twice identified some issues, and both times I replied that it is acceptable to constrain the actions so as to avoid those issues.


>> If the clients would like to see the keys in the configuration then
>> they can monitor <operational> (or <intended>), and then add the keys,
>> either in raw form, or encrypted in some way.  But I still think that
>> it is architecturally cleaner if it is always the client that updates
>> the <running> configuration and never the device.
> 
> I agree.  I think it would be worthwile to explore the
> "non-action-based" solution that Rob proposed.  Is there anything in
> that solution that doesn't work?


I discussed this option in my "wide-screen needed" email from last Friday.
There are 3 cases to consider:

1) the manufacturer creates the (most likely "hidden") key pair and associated certificate.
      - these nodes MUST originate in <operational> (origin="system")
      - clients MUST replicate their (potentially encrypted or "permanently-hidden"
        enumerated) content into <running> in order reference the key and/or cert.

2) the client wishes to generate a key (hidden or not) without ever touching the
    private key.
      - presumably this occurs via a "generate-key" action (open to ideas)
      - this key ultimately MUST be in <running> in order to be referenced by config.
      - ideally it shows up in <running> as consequence of invoking the action.
      - less ideal, as in (1), a <get-data>/<edit-data> sequence could be used
        to bring the key into <running>.

3) the client wished to installed a hidden key.
      - note that we don't discuss installing a non-hidden key here, because
        that is exactly what a standard <edit-config> operation does.
      - presumably this occurs via a "install-key" action (open to ideas)
      - this is a weird case because the client is initially okay with touching the
        private key, but thereafter wants it to be protected by the system.
      - again, as with (2), ideally the key shows up in running as consequence
        of the action, but a round-trip could also get it there.


Kent // contributor