Re: [Netconf] Mandatory local configuration in Keystore groupings
Martin Bjorklund <mbj@tail-f.com> Tue, 28 August 2018 19:23 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 E5972127B92 for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 12:23:41 -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 mZumGRPhLxPc for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 12:23:39 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE14126BED for <netconf@ietf.org>; Tue, 28 Aug 2018 12:23:39 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id D40FF1B039EA; Tue, 28 Aug 2018 21:23:38 +0200 (CEST)
Date: Tue, 28 Aug 2018 21:23:38 +0200
Message-Id: <20180828.212338.1325240417175615395.mbj@tail-f.com>
To: balazs.kovacs@ericsson.com
Cc: kwatsen@juniper.net, balazs.lengyel@ericsson.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <VI1PR0701MB2016F2754609FAEC242C9D51830A0@VI1PR0701MB2016.eurprd07.prod.outlook.com>
References: <AD108D78-8E5D-429B-AFA9-8C84430F5186@juniper.net> <20180828.090648.398453385489817261.mbj@tail-f.com> <VI1PR0701MB2016F2754609FAEC242C9D51830A0@VI1PR0701MB2016.eurprd07.prod.outlook.com>
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/wlfy_IO6PGwaZ-ugLaYaYwRAfts>
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 19:23:42 -0000
Hi, Balázs Kovács <balazs.kovacs@ericsson.com> wrote: [...] > Balazs> In our opinion with Balazs L., we think it would be > disadvantageous to change the model by ruining the containment > relationship between certificate and corresponding asymmetric key. The > action of 'generate-asymmetric-key' is typically something that should > have effect on the 'running' configuration too (by setting the > mandatory leaves) since the user wants to continue working with the > result by deploying certificates or anything else related to the > created asymmetric key that needs configuration. > > Balazs L.> In the NMDA RFC it is specifically indicated that > actions/rpcs MAY modify the content of other datastores. > https://tools.ietf.org/html/rfc8342#section-6.2 > In my view this is a general pattern that an action/rpc creates some > configuration that the operator (CLI/Netconf/Restconf) may need to > extend or change. In this case the action/rpc shall modify the running > config not just operational. I think that special actions/rpc that modify config should be avoided in probably all cases. The text in 8342 handles generic rpcs like "edit-data" etc. *if* you design an action to modify config, it needs to take at least the datastore as an input parameter. In this particular case, I see no reason to have a special action to modify the configuration of keys. /martin > > Br, > Balazs K. and Balazs L. > > -----Original Message----- > From: Netconf <netconf-bounces@ietf.org> On Behalf Of Martin Bjorklund > Sent: Tuesday, August 28, 2018 9:07 AM > To: kwatsen@juniper.net > Cc: netconf@ietf.org > Subject: Re: [Netconf] Mandatory local configuration in Keystore > groupings > > 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 mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf
- [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