Re: [Netconf] Mandatory local configuration in Keystore groupings
Martin Bjorklund <mbj@tail-f.com> Tue, 28 August 2018 07:06 UTC
Return-Path: <mbj@tail-f.com>
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 A13FA130E51 for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 00:06:54 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1lzw5C7WnqIE for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 00:06:53 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CD75E12F1A5 for <netconf@ietf.org>; Tue, 28 Aug 2018 00:06:52 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 684C71AE0449; Tue, 28 Aug 2018 09:06:49 +0200 (CEST)
Date: Tue, 28 Aug 2018 09:06:48 +0200
Message-Id: <20180828.090648.398453385489817261.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <AD108D78-8E5D-429B-AFA9-8C84430F5186@juniper.net>
References: <28C3C2C7-22BE-4425-A26C-4A777FA68A95@juniper.net> <20180827.102118.630809612057220140.mbj@tail-f.com> <AD108D78-8E5D-429B-AFA9-8C84430F5186@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/DAhyejOg8Lc0yTLCKdDxxCo5Fq4>
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing 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, 28 Aug 2018 07:06:54 -0000
Kent Watsen <kwatsen@juniper.net> wrote: > > > > > BTW, all private keys should have nacm:default-deny-all. > > Updated in my local copy. Added to the "asymmetric-key-pair-grouping" > grouping, so all downstream users inherit it as well. > > > > > I think that the operation "generate-asymmetric-key" only affects > > "permanently-hidden" keys, doesn't it? If the client wants visible > > keys, it will configure them in the config datastores. > > It wasn't so locked down before. How about the following two changes? > > 1. Updated the action's description statement: > > action generate-asymmetric-key { > description > "Requests the device to generate an asymmetric key using > the specified asymmetric key algorithm. This action is > used to request the system the generate a key that is > 'permanently-hidden', perhaps because it is protected > by a cryptographic hardware module. The resulting > asymmetric key is considered operational state and > hence present only in <operational>."; > > 2. updated the enum's description statement: > > enum "permanently-hidden" { > description > "The private key is inaccessible due to being > protected by the system (e.g., a cryptographic > hardware module). It is not possible to > configure a permanently hidden key, as a real > private key value must be set. Permanently > hidden keys cannot be archived or backed up."; > } Ok. > > > Regarding the name, s/hardware-protected/permanently-hidden/? > > > > I think this is better. > > Okay, but maybe it should be just "hidden"? Both work for me. > >> Now you have me second-guessing this. Maybe a device, without special > >> hardware, could present the illusion of a permanently-hidden private > >> key - it's completely inaccessible from the device's supported > >> interfaces, though actually present on the filesystem. > > > > This is what I would like to support. > > Okay. > > > > >> >> Unsure what you mean. Currently all these values are configurable. > >> >> Or are you trying to find a way to only "configure" them in > >> >> <operational>? > >> > > >> > Yes, *if* my use case of not exposing the private keys is supported, > >> > then it would be useful to be able to generate the keys off-box, and > >> > install them into <operational>. > >> > >> Hmmm, sounds like *configuration*, not something goes into <operational>. > >> > >> And, even if you did, that doesn't mean the keys are permanently-hidden. > >> I suppose the model could let the client set that parameter as well, > >> but it somewhat defeats to goal of *never* having the private key exposed, > >> not even as a once in a lifetime kind of thing. That’s just my opinion, > >> we should ask for more opinions if you're not convinced. > > > > I'm not convinced either way, actually ;-) It would be good to hear > > other opinions as well. > > We could define a "load-asymmetric-key" action that has that behavior? Yes; if we decide to support this use case. What do others think? > > This is what I would expect as well, but the model is not quite > > designed for this currently. For example, suppose I generate a > > HSM-protected key with "generate-asymmetric-key". It is then present > > in <operational>, with a public key etc. Now I want to configure a > > certification for this key, so I have to create an entry in the > > "asymmetric-key" list, where I have to set both the > > private-key and public-key leafs (they are both mandatory); so I > > assume I have to use the exact values reported in <operational>? > > Hmmm, using the same value could work, but it doesn't seem intuitive > and, from a general modelling perspective, doesn't scale e.g., what > if there were 100 descendants? Exactly my point. > A couple other options: > > a) make each leaf (algorithm, public-key, private-key) type be a > union having an enumerated value like "in-operational" This feels clumsy and also doesn't really scale. > b) replace the three "mandatory true" with three "must" expressions > that assert either all or none of the leafs are set. Better, but also has scaling issues in the general case. > > Another design could be to have the certificates in a separate list, > > with leafrefs (require-instance false) into the "asymmetric-key" > > list. > > Perhaps, but let's see if we can make this work first. Ok, let's look at the alternatives: (A) container keystore { container asymmetric-keys { list asymmetric-key { key name; leaf name { ... } leaf algorithm { ... } leaf public-key { ... } leaf private-key { ... } must "(algorithm and public-key and private-key) or not (algorithm or public-key or private-key)"; container certificates { list certificate { ... } } } } (B) container keystore { container asymmetric-keys { list asymmetric-key { key name; leaf name { ... } leaf algorithm { mandatory true; ... } leaf public-key { mandatory true; ... } leaf private-key { mandatory true; ... } } container certificates { list certificate { ... leaf key { leafref { path "../../../asymmetric-keys/asymmetric-key/name"; } require-instance false; mandatory true; } ... } } } I think model B is cleaner. /martin
- [Netconf] Mandatory local configuration in Keysto… Balazs Lengyel
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen