Re: [Netconf] Mandatory local configuration in Keystore groupings

Balázs Kovács <balazs.kovacs@ericsson.com> Tue, 04 September 2018 08:34 UTC

Return-Path: <balazs.kovacs@ericsson.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 E33E5130E42 for <netconf@ietfa.amsl.com>; Tue, 4 Sep 2018 01:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=axhegOlH; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lYm7FZta
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 o4l33t2-luLM for <netconf@ietfa.amsl.com>; Tue, 4 Sep 2018 01:34:41 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828F3130E2D for <netconf@ietf.org>; Tue, 4 Sep 2018 01:34:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536050078; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=thjTilLa7W54OxSzLtJWfR9GTkFze+NwisP3NGrLPuo=; b=axhegOlH+Qip22ya6TKawhWqIhgVS8P4luKvDx92st/hn7smUIV4QMYbAJ2Jw+Gl 8RWHCHXNIxZSULVg5Xhmfa/QXvpfNPTIUMILwV/08H8s51GFLmGdMkqd2gOK2YJD LTI6XXQ9b/Ujf4ur8ACM5221ST86JzbLijUcE7/oz1c=;
X-AuditID: c1b4fb25-8e7ff700000013ad-4e-5b8e439e6e41
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B6.44.05037.E934E8B5; Tue, 4 Sep 2018 10:34:38 +0200 (CEST)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Sep 2018 10:34:38 +0200
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 4 Sep 2018 10:34:38 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hkAv1FBcGNZ14rP+vw5pVcCZ9jd5S8eWv35KyklTtec=; b=lYm7FZtaEBHWqpg0tOCYdR0fv93kaBNoeMrIg1mOAZbSalNubhuAzTh1hgYyVtmWiaKuHKwY/812Xq9Ah7HlhSSdqc1bv4bippvrZeVCT4/h6jm67y+QBvpWFkYbioQauDqCeYhdtGMtAkR1hZHzUhMEa4bLQWzXzwy8gsrnYwA=
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com (10.167.209.150) by VI1PR0701MB2048.eurprd07.prod.outlook.com (10.167.210.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.12; Tue, 4 Sep 2018 08:34:36 +0000
Received: from VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9]) by VI1PR0701MB2016.eurprd07.prod.outlook.com ([fe80::bd7a:c3c7:f6f1:4e9%4]) with mapi id 15.20.1122.009; Tue, 4 Sep 2018 08:34:35 +0000
From: Balázs Kovács <balazs.kovacs@ericsson.com>
To: Martin Bjorklund <mbj@tail-f.com>, "kwatsen@juniper.net" <kwatsen@juniper.net>
CC: Balázs Lengyel <balazs.lengyel@ericsson.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Mandatory local configuration in Keystore groupings
Thread-Index: AQHUE4npYduSZhsf/U2Th8xceQbCUaSAzHaAgEmH34CAAG1ZgIAA+nAAgAPuH4CAA+yKAIABAxSAgAB6cACAAHFXIIAAWSCAgADMp9CAAnp9gIAFkemAgAFwH/A=
Date: Tue, 04 Sep 2018 08:34:35 +0000
Message-ID: <VI1PR0701MB20166AC7017AACC865EAE4AC83030@VI1PR0701MB2016.eurprd07.prod.outlook.com>
References: <C08E28A2-DB24-4456-969F-695F3EF8701D@juniper.net> <VI1PR0701MB20167F4B50F4D92FA34A79AC83090@VI1PR0701MB2016.eurprd07.prod.outlook.com> <C739EADD-F458-4939-AEBD-59519586FE81@juniper.net> <20180903.121823.1406711858636851159.mbj@tail-f.com>
In-Reply-To: <20180903.121823.1406711858636851159.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [89.135.192.225]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2048; 6:EjsCApBjkR3k1HLuJFVWL5TxBbQTqH22Y8xPDioZ4pjrfzUSv+ca7Ehz+YK4fKrzEtTYrWjsqsbxj9o8w/+3ZSrg+aRPTT1aSxDPBaArBtsLH4OSxCxfUduWHvhi32Uo27uvAm2+8ulV2pFQlY5YIOItWdwA1ybay28Pl+eotvDjiRpwWe5VyZj1uH2OFjprVbEk7WfWUqvcD4XQ3X/kT44WnrmnMomKk8OmNoSy4LM/pRrINNDPrzHOC3j2/9kEZzzDbU34IrcaKdiVRb4hBxKYI2JxHa1lbV4yiNdfrFZDupNVhpJ8KG6hvsJLKtdBB3izdhbJqcgWALpVXvScd4/5FNx+h5vLjzXLPDWA4fNX96R9pqwrpp58Y6zLBxi7AqselDQ30w0+N4Sh/hreppehS+5tf96ZCXoGL+Y+RiNh6nc27UUcWTiuuUpMfZXYBUxpF2ri2igY5ImkJwjDNA==; 5:m3fQl4cPrE00tmhDYAA9i1xGNpOcBOIMgsfwWvsKmSA9Hdy1x0XPIB1WlhNX+bDuXw0CmsttzSpYqxoBwxyz9CwsyKF/0ErApPaBy/NcMY1S1B5+JdX/vQcKZe+aSsJfPcfyLHOlOAYc50MR2qyUlXGfhsLqUv6qeWG9YZOWG/w=; 7:ZAXOw7gvwAbeIjAL+EzK9cdzlyi96F7TvzVds7Jy2v4oP6KL5U1WrCvxjBvJg///VGMFwXKYYjd1I+zhT6EaG8MwydXyqkNGCvOdVoPpK2DTBQ8xE6asmSDbXfQBREhfTibaOi/SjeSGJSQtBQfiOfX/cAqGwfkYYzy3hDZK4ncy331sEFghZaj0HaVSqNe7hI6Mf3X0LP0FS4Ilbq2cdzvOqqlq8bOQuSk1+6Hwl2CqScAIt4FQjjnmLTihbHSg
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(346002)(376002)(396003)(199004)(189003)(13464003)(1941001)(102836004)(256004)(53546011)(14444005)(5250100002)(6506007)(93886005)(14454004)(2501003)(2900100001)(4326008)(7696005)(33656002)(110136005)(99286004)(316002)(54906003)(229853002)(7736002)(55016002)(305945005)(9686003)(6436002)(74316002)(8676002)(97736004)(53936002)(81156014)(186003)(26005)(11346002)(476003)(486006)(446003)(86362001)(105586002)(81166006)(5660300001)(8936002)(25786009)(68736007)(76176011)(2906002)(106356001)(6116002)(66066001)(3846002)(6246003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2048; H:VI1PR0701MB2016.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-office365-filtering-correlation-id: e9772c43-fdb8-4f50-5595-08d612413efc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0701MB2048;
x-ms-traffictypediagnostic: VI1PR0701MB2048:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.kovacs@ericsson.com;
x-microsoft-antispam-prvs: <VI1PR0701MB2048EF26DE95A49C46BDC59583030@VI1PR0701MB2048.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(138986009662008)(248295561703944);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(823301075)(3231311)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699049)(76991033); SRVR:VI1PR0701MB2048; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2048;
x-forefront-prvs: 0785459C39
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: rgFnn334VIDay4HMMZg8ZJ1SjoyHZBmBwTzuT4baXPDQvFTV8d8jSnYEkJwxV/7ca3NJnJFW2FH9YmoFUoneqjet0CV9Ylw1zJGrSPF45/xsMp9fLPCRUj6IuDAGR/3vOaeUHhOsX98PEqJ+oPEIvqd1uDZW50wQ246RRzf8DZ09RRlgoik0wVgmkHgiwHdVvn1BIGhrxEtj11NXhWpgNNDcvPO5KO6YkgcJO6IGyTRvyc4IZZhGOr11zCgIbq2G7tr6w8mHA8Kwkomqe12lDuWDmEhD9cbIezBB7Leri9lP4T+hGRaOd3lEYbjQswsTmd6L1OhmOa3EeeCXBy4qvu9IiUliQ0Ne9XPa8Gnbrkk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e9772c43-fdb8-4f50-5595-08d612413efc
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2018 08:34:35.7161 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2048
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUyM2J7ue48575og3ubDCwOzGG36O5+xm4x ddNtVgdmjyVLfjJ5XG+6yu6x8ddilgDmKC6blNSczLLUIn27BK6Mnh9vmApe21bcmfGepYHx iH4XIyeHhICJxKlTr9i6GLk4hASOMkoc+HGVEcL5yijRcG0OE4SzmEni65kOVhCHRWACs8Tp I6uYITLTmCT+zz3NBjJMSOAxo8SyCUIgNpuAq8TTmT/ZQWwRgRCJroWTWEFsZoEciaZvqxlB bGEBL4lde28zQtR4S/R072cBGSoi0MUocWbveRaQBIuAisTxx1uZQWxegQSJvm8LWCA2NzJJ TFxxCKybU8BR4kL7KyYQm1FATOL7qTVMENvEJW49mc8E8aqAxJI955khbFGJl4//sULYShIz Xt2CsmUlLs3vBoeAhMABdonGW21QCUOJ4yv3M0MkGtgk1rz4wwKR8JXYsuoMG0RiO6PEqubF UCt0JB4e+g91UqzEjtd32CHi+RLTty+HqomReLP3MesERsNZSK6FsPUkbkydwgZha0ssW/ia eRY4CAQlTs58wrKAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBKObjlt+oOxstvHA8x CnAwKvHw/jftixZiTSwrrsw9xCjBwawkwuvHDxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO+9B8 c5SQQHpiSWp2ampBahFMlomDU6qBcfKr9KaWJW7xF6Oun5saOfHIfHeNN6Xb3steNAw8vthO b6LcqvWMYtvU+zh4Popvs06//L3f5YEYc+O7qPQdHy0PylY0+jO2Ou3SdKpsSWf4zTC38cPq Fj7+/N8GHV27ApTPOxwpenAw0THjUf/EAI/0CXcrxEzzVy1Y//abUrhJTfBkZYsIJZbijERD Leai4kQAn/rohSUDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/SP1jRipNKEQ5LM8DneYCdFLA7x8>
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, 04 Sep 2018 08:34:43 -0000

Hi Martin,

I prefer your alternative (C) with some comments.

I'd keep the name of the action as 'generate-asymmetric-key'. I think the word 'asymmetric' gives a hint on its intended use case, so it is important (though it is already in an asymmetric-key list). The word 'hidden' is not that important for me since the action in itself hints that the key in this case is not provided by the operator, thus its binary value won't appear either. If operator needs to provide it, it has to go via the 'private-key' leaf. Or the action could be just called 'generate-key'.

A question still: it is unclear to me what the difference is between calling the action vs just configuring the 'private-key' to enum 'hidden'.

Br,
Balazs


> -----Original Message-----
> From: Martin Bjorklund <mbj@tail-f.com>
> Sent: Monday, September 3, 2018 12:18 PM
> To: kwatsen@juniper.net
> Cc: Balázs Kovács <balazs.kovacs@ericsson.com>; Balázs Lengyel
> <balazs.lengyel@ericsson.com>; netconf@ietf.org
> Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
> 
> Kent Watsen <kwatsen@juniper.net> wrote:
> > > Balazs> The certificates in keystore are useless without a
> > > Balazs> corresponding
> > > private key, so certificates of a key cannot be in the configuration
> > > tree once the corresponding key is removed. By the way, how would a
> > > private key be removed from <operational> if it does not exist in
> > > configuration? If you do it with an action too, how would the
> > > corresponding certificates be removed from the configuration?
> >
> > Good points.
> 
> Yes.  The lifecycle of keys are not handled fully in the current draft.  But I
> think that if this is done properly, separating the config of keys and
> certificates would not change the lifecycle of how keys.  So let's first discuss
> how we want to handle creation and removal of the hidden keys (configured
> keys are not a problem).
> 
> With the current draft, a hidden key is created in <operation> with an action
> and may not be present in <running> and <intended>.  There is no way to
> delete such a key.  We would have to create a new action to remove it.
> 
> An alternative design could be to move the action "generate-asymmetric-
> key" into the "asymmetric-key" list (and maybe rename it to "generate-
> hidden-key").  A client would then first have to configure an entry in the
> "asymmetric-key" list, and then it can generate the hidden key.  If the
> asymmetric-key list entry is removed from <intended>, then presumably the
> corresponding hidden key is removed as well.
> 
> With this design, a separate "certificate" list could have normal leafref
> (require-instance true) into the "asymmetric-key" list.
> However, with this new design my original issue with how certificates are
> handled goes away, so having them contained in the "asymmetric-key" list
> works fine.
> 
> > >> Martin makes a case for 'B', but he also said that my 'b' was
> > >> "Better" but has scaling issues in the general case.  Perhaps we
> > >> don't worry about the general case here?
> > >
> > > Balazs> Was it so? I saw an A and B model, A containing
> > > must "(algorithm and public-key and private-key)
> > >              or not (algorithm or public-key or private-key)"; and B
> > > containing the keys and the certificates in separate container, and
> > > a note "I think model B is cleaner".
> >
> > Right, but if you scroll up higher, I had previously had an (a) and
> > (b) [note lowercase] to which he said (b) was "better".  Maybe it's
> > moot, since his (A) was effectively my (b).
> 
> Here's the new alternative:
> 
> (C)
> 
>   container keystore {
>     container asymmetric-keys {
>       list asymmetric-key {
>         key name;
> 
>         leaf name { ... }
>         leaf algorithm { mandatory true; ... }
> 
>         leaf public-key { ... }
>         leaf private-key { ... }
> 
>         // ensure that both or none are given
>         must "(public-key and private-key)
>               or not (public-key or private-key)";
> 
>         action generate-hidden-key { // no input params }
> 
>         container certificates {
>           list certificate { ... }
>         }
>     }
>   }
> 
> A possible extension to this would be to add anoter action next to
> "generate-hidden-key":
> 
>    action install-hidden-key {
>       leaf public-key { ... }
>       leaf private-key { ... }
>    }
> 
> 
> One case to consider is that there may exist an entry in <intended> that has
> been configured but no hidden key has yet been generated.
> Such an entry would then not exist in <operational>, and the action
> "generate-certificate-signing-request" would fail.
> 
> 
> 
> /martin
> 
> 
> 
> > My point is that the containment approach 1) does resolve the he
> > primary goal (configuring a cert for a key in <operational> and 2) I'm
> > not concerned about the general scaling problem.  By "perhaps we don't
> > worry about the general case here?", I mean to say that I prefer
> > keeping the containment approach.
> >
> >
> > > If I got it well, model A would keep the containment and produce the
> > > key name after invoking the action (affecting the configuration
> > > tree!?) at least covering the key removal use case properly.
> >
> > Invoking the generate/load-asymmetric key actions, as thus far
> > dscribed, would NOT affect the config tree (i.e., <intended>), only
> <operational>.
> >
> >
> > > Balazs> If the key generation and load only affects the
> > > Balazs> <operational>
> > > only, I would rather vote for model A having the containment
> > > relationship between key and certificate(s).
> >
> > This is my preferred approach as well.
> >
> >
> > > Plus, I would also think about the mandatory statements in the
> > > configuration tree whether all 4 leaves (name, private-key,
> > > public-key, alg) or just name and private key needs to be configured.
> >
> > I'm think all four are needed.  Only public-key is possibly not
> > needed, but it's trivial to ask a client to pass it, so why not?
> >
> >
> > > ...but why use an action at all then?  Everything can be done via
> > > standard configuration, right?
> > >
> > > Balazs> That is actually a good question. Until the enum had the
> > > literal 'hardware-protected' only the configuration use case of the
> > > private-key was a bit unclear. Now I assume configuring the
> > > private-key as 'hidden' could do the same as generate-private-key,
> > > but in that case the operator has no means to configure the public
> > > key (the removal of the mandatory condition for the public key could
> > > solve this). Regarding 'alg', I guess if hidden private key is
> > > asked, then algorithm is an input, but if binary private-key is
> > > configured, then it is rather implicit. Would the action be needed
> > > then?
> >
> > There are a few things off in what you write, but the most important
> > thing is that there is no way to *configure* (via <intended>) a hidden
> > key.  Trying to do so, by passing the "hidden" enum, means that the
> > real private key raw data would NOT be set!
> >
> >
> > > Balazs> The action in this case seem to make sense only if the
> > > purpose of the actions is really to only affect <operational>.
> >
> > Yes, that is the intent.
> >
> >
> > > But based on the above, I doubt yet how affecting configuration can
> > > be avoided (even with alt A -> to maintain consistent composition of
> > > key and cert) I think this question goes back to some YANG
> > > principles and is beyond my YANG competence.
> >
> > I'm not following, can you say a different way?
> >
> >
> > Kent // contributor
> >
> >
> >
> >