Re: [netconf] ietf crypto types - permanently hidden
Kent Watsen <kent+ietf@watsen.net> Mon, 29 April 2019 16:17 UTC
Return-Path: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-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 64F45120168 for <netconf@ietfa.amsl.com>; Mon, 29 Apr 2019 09:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, 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 DuEL1aHAogIh for <netconf@ietfa.amsl.com>; Mon, 29 Apr 2019 09:17:52 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50E612032A for <netconf@ietf.org>; Mon, 29 Apr 2019 09:17:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556554671; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=a0C1nJ42ohP9FEL3z4FKnHYYnEKlLZcjvlak9Dv9ZkY=; b=hBp8QPnnCaQ3XHCuIVqWx6XU1v/6jcE1CUs0+PAz4Fo5CA0/5qf6/F7eAcEQwd+C iKG+nJLTLBBIwY5nI9fSOepE9p4UNs7/tYAUKY3CygLAL49aEa8dSAueqi7C5NMuiwc kC8RUB4wSehgRL1AtMlAUFlKztRNIoj+97fgCwAg=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016a69e36565-37279712-e5de-4c48-9a8a-7397d54c11b3-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_337CEA86-1976-4F0E-BADD-0964C68E94A8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 29 Apr 2019 16:17:51 +0000
In-Reply-To: <VI1PR07MB4735FEEE1303E361B3B44FA983390@VI1PR07MB4735.eurprd07.prod.outlook.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netconf@ietf.org" <netconf@ietf.org>
To: Balázs Kovács <balazs.kovacs@ericsson.com>
References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com> <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com> <VI1PR07MB4735949BE61335ACC8A975E7833C0@VI1PR07MB4735.eurprd07.prod.outlook.com> <0100016a5019d7f9-7f737c63-d07c-4c7f-b12e-c5b19d50eeaf-000000@email.amazonses.com> <20190424180513.gtxmreicd7iydrpr@anna.jacobs.jacobs-university.de> <0100016a510a3038-7671e146-e23f-4bc9-9f93-ea2314b5d4e7-000000@email.amazonses.com> <VI1PR07MB4735FEEE1303E361B3B44FA983390@VI1PR07MB4735.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.04.29-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/VOv9MxevodSLou7Oe4cGRaXTDbM>
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: Mon, 29 Apr 2019 16:17:54 -0000
Okay, I've added the following text into the generate/install-hidden-key descriptions: OLD: The resulting asymmetric key values are considered operational state and hence present only in <operational>."; NEW: The resulting asymmetric key values are considered operational state and hence present only in <operational> and bound to the lifetime of the parent 'config true' node. Subsequent invokaions of this or the '<other>-hidden-key' action are denied."; where <other> is the name of the other action (generate vs. install). Kent > On Apr 29, 2019, at 8:24 AM, Balázs Kovács <balazs.kovacs@ericsson.com> wrote: > > Hi, > > Kent, I'm fine with your proposals. > > Regarding subsequent calls to the actions, I agree the safe choice would be to deny them; otherwise, one could run into invalid key pairs (where a certificate was already configured) and authentication failures with network peers (especially in SSH-key-based-authentication case). > > Br, > Balazs > >> -----Original Message----- >> From: Kent Watsen <kent+ietf@watsen.net> >> Sent: Wednesday, April 24, 2019 10:30 PM >> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> >> Cc: Balázs Kovács <balazs.kovacs@ericsson.com>; netconf@ietf.org >> Subject: Re: [netconf] ietf crypto types - permanently hidden >> >> Hi Juergen, >> >> >>> Perhaps this should say 'implementation specific' instead 'application >>> specific'. >> >> Changed in my local copy. >> >> >>>> My recommendation is to modify the "generate/install-hidden-key" >> (renamed to just "generate/install-key") actions to have a flag indicating if >> the key should be "permanently hidden" (perhaps by using a TPM) or not, in >> which case configuration is created, same as if the client had used <edit- >> config>, but without needing to touch the key. >>> >>> I agree that having a flag to control the behavior is useful and I >>> think there should be explicit text how the action fails in case the >>> requested action cannot be performed. >>> >>> I am not sure I understand install-hidden-key. The description says: >>> >>> "Requests the device to load the specified values into >>> a hidden key. The resulting asymmetric key values are >>> considered operational state and hence present only in >>> <operational>."; >>> >>> So what is the persistence model of this? Does a key installed with >>> install-hidden-key survive reboots? If so, can I delete somehow such a >>> hidden key? (Is the answer that this key is tied to the lifetime of >>> the list element indirectly using this grouping?) Does invoking >>> install-hidden-key twice cause the first installed key to be >>> overwritten? Can the install-hidden-key action fail in any way? >>> >>> This leads to related questions for generate-hidden-key: Does invoking >>> this action twice cause an existing key to be overwritten? Can I >>> explicitely delete a generated hidden key? Does deleting the list item >>> that directly or indirectly uses this grouping delete a hidden key? >> >> [Disclaimer: the below reflect my understanding of how the current model >> works, and does not necessarily reflect if we were to flip things around by >> letting the actions generate configuration.] >> >> The expectation is that the "permanently hidden" keys would persist, >> presumably with origin=system. >> >> In the YANG, the "permanently-hidden" enum only appears in the >> "asymmetric-key-pair-grouping" grouping. Consuming data models are >> expected to "use" this grouping under a "config true" node. This grouping's >> description statement is noteworthy: >> >> grouping asymmetric-key-pair-grouping { >> description >> "A private/public key pair. >> >> The 'algorithm', 'public-key', and 'private-key' nodes are >> not mandatory because they MAY be defined in <operational>. >> Implementations SHOULD assert that these values are either >> configured or that they exist in <operational>."; >> ... >> } >> >> Thusly it is expected that the client will create the parent node (e.g., via >> <edit-config>) and then invoke either the generate or install hidden key >> action. Presumably, the lifetime of the permanently hidden key would be >> tied to the lifetime of its parent. >> >> Regarding what happens when the actions are invoked a second time, it's >> not specified. One choice, perhaps the safe choice, would be to deny >> subsequent attempts, forcing the client to create a new parent node instead. >> If the parent node is in a list, such as in the keystore, then the second key >> could be created, with certificates bound to it, before mapping reference to >> the old-key to the new-key. However, if the key is not in a list, such as when >> using a "local-definition", then in in-place migration, along with service >> disruption, would be required. >> >> Of course, one has to ask how often/likely is it that a client wants to >> regenerate the private key. Presumably it would only be due to the concern >> that the key had been compromised (which shouldn't happen if >> "permanently hidden") or, perhaps, due to a proactive key-rotation policy, >> thinking (misguided, I believe, proven false now) that the private key's >> entropy expires over time. Regardless, the point is that it seems to be an >> action that would seldomly occur and, when/if it does, the effort to create >> another parent node (in keystore or a local-definition) might not be a big >> deal. >> >> PS: words such as "expectation" and "presumably" are used above to >> indicate a likely need for the text to be more explicit. >> >> Kent // contributor >> >
- [netconf] ietf crypto types - permanently hidden Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Balázs Lengyel
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Andy Bierman
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Andy Bierman
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Andy Bierman
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen