Re: [Netconf] Mandatory local configuration in Keystore groupings

Kent Watsen <kwatsen@juniper.net> Tue, 11 September 2018 00:58 UTC

Return-Path: <kwatsen@juniper.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 4C00C130DE2 for <netconf@ietfa.amsl.com>; Mon, 10 Sep 2018 17:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, 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 (2048-bit key) header.d=juniper.net
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 izXq1O1GtRuo for <netconf@ietfa.amsl.com>; Mon, 10 Sep 2018 17:58:21 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 3D8AB1271FF for <netconf@ietf.org>; Mon, 10 Sep 2018 17:58:21 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8B0rVsx022553; Mon, 10 Sep 2018 17:58:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=mXkWCJxDYhJBJbH4o68/IGYLmcohPO7to5zV4IKJOG8=; b=AlpEXrlQOvedCnv9JQPsTp7G6CrECZsDrom4x+EtsZzmzlEe1qWOL+tP2DVKHc0Vz6BH FvZCh0aDsjwn4K1GrHMEfvCU5WLmqi4OcM+6CuRXe7n3gtm0zN5oAw6mxkoNOHW5Cm5o 3qXq7i6cFJ7TKm8gVqYfn0PpbDGkuBtcRlYWOnVWTQMKYGvsNK4Ab+okQJ+OnBYOepwl D6zPgbNMD4ambWF340Cxt1oK8g66KOMDYo13FUtujl5/fSm+g8EdoNK3CD9SJciSVb1F b95jc3LZsdtZjO6/b8c1QbnTaZEn3dputP+hJX0Twyt3CcWCRZXnT31otC2SsDIAW78Z cw==
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0083.outbound.protection.outlook.com [216.32.180.83]) by mx0b-00273201.pphosted.com with ESMTP id 2mdy48re0c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Sep 2018 17:58:18 -0700
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4300.namprd05.prod.outlook.com (20.176.78.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.11; Tue, 11 Sep 2018 00:58:16 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::544a:dd4d:9524:9e6d%5]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 00:58:16 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Balázs Kovács <balazs.kovacs@ericsson.com>, Martin Bjorklund <mbj@tail-f.com>
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: AQHUE4rJV5t3ZASQT0G65kk51KFdjKSAiWUAgEnK74CAACpJAIABPX8AgAOrEACABC+ZAIAAwASAgAC9gACAAHNjgIAAFAaAgAEgEwCAAicPgIAF1PmAgAF1VYCACj3EgA==
Date: Tue, 11 Sep 2018 00:58:16 +0000
Message-ID: <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net>
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> <VI1PR0701MB20166AC7017AACC865EAE4AC83030@VI1PR0701MB2016.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR0701MB20166AC7017AACC865EAE4AC83030@VI1PR0701MB2016.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4300; 6:yDYBh0BYJG9Kys+3qQb1S2ZuR9hvwir9ocXW/Jo0ij7vB0gtcFQ+6tyPyjrDor0H5e0k2m/qfiTCYFg/lzq2RWquT+BVFIiERw5P0BbtmjY0ZH/kYNB5GJ/7kyvbIFgT6Gl0K0BzgnyawOajfGkLZ5JByUKnbx8dOPQqMsq32z2VyxCKbgxaXTLZsbjmzKbEMmO71leMyEnpDO81n0AaMwMQAPPTpqp+6VM0KPwiH+R42FjycoSiID8exAbfFUx3nBmPSMiz8REKwpV4YWLuOOBMqU2NdC89KQl/5UNkEsna8jsbgXxvkiQpcPd0Qp6PVvNdNOf/Eo4j2bIeUYHRnrcIfu0L1sZUbBEnfMmmJT6Us1C8PK1hq10NotYVn4iJ/syqU4SxjXVNc+gdGmZMek7OfWmYX/oYjBnFKvEZ5GMBuN4F1xWMdeGN4byZgpIac+nH33t5WKrPuVgC39xM6Q==; 5:TrjYK6Te7rqBO/ndG5MrlXrYF46PcD7BrnsNc4buy2FWmKw5r8Fa4hnKYI2AlCHRenVrj44SJAFo3kP8+wpo7LJ4t5N5lT/t26QokXlpDvB3Mt1eL0E3JLUUIBDj1PoBq9NVLHkYkyjTW2ZN7ExZoz3X37TdQYDbIfI+DzSBjJY=; 7:mGplUMRGcgRuHuPDZTf6r9mllUecQkmeTB1qc1yObdyZYO0Mr4uygmSXwCHbp24GC+AocjIbZ9BP6tp4EXjEqpQoXt7XBdicU1eGgyc/gLUWIfHoz3v3HT/IPR3ydKToijR+YUSJt8UnwIdPItdlvtk8T2IwaJ9b0R+2uBxtB3IUf1hfpIoyi/6Hpaf7hyWo6rpNJE8Ke0e9PRA/LTsZU73z7gAcrmiYnZ+asysKA1IV2sgMyKaRxsHi6lbz3WG6
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 078ae5cb-7a0c-4ec2-b243-08d61781a8b1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4300;
x-ms-traffictypediagnostic: DM6PR05MB4300:
x-microsoft-antispam-prvs: <DM6PR05MB4300F198D1581F042C9D4B45A5040@DM6PR05MB4300.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(138986009662008)(248295561703944)(17755550239193);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231344)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699050)(76991033); SRVR:DM6PR05MB4300; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4300;
x-forefront-prvs: 0792DBEAD0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(346002)(376002)(39860400002)(189003)(199004)(13464003)(66066001)(6246003)(93886005)(11346002)(486006)(81156014)(81166006)(36756003)(33656002)(14444005)(102836004)(76176011)(6512007)(5250100002)(4326008)(476003)(446003)(2616005)(6346003)(26005)(186003)(105586002)(53936002)(229853002)(256004)(106356001)(6116002)(6436002)(14454004)(3846002)(97736004)(99286004)(6506007)(53546011)(86362001)(68736007)(8936002)(54906003)(25786009)(110136005)(2906002)(316002)(58126008)(82746002)(6486002)(8676002)(2900100001)(7736002)(5660300001)(305945005)(478600001)(83716003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4300; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: vX94IGBQZeZLyrS2vVTWaN+dMpY7dwynimCD7BsHnrtCAHZDoB5v7kaw6CzHj9IbmR1rkoDUSIr7xQMsiOCEXgEk+nAJ65FGjvtFNDHpUklwK8UmrKDUjh4PKF/BktyMFNLK98VT4k57aaYhKqOFks+xxvu/U9Eek9Az/caftzY+NAMmr3QL28mC7emhQDArMJuKuC1P8PAMMkepy8p6CdY8se/fYFWneLo1Dsro8fAPUhVSjQdQs0KlSX38eR7ubMPuVWCiSc1A/+2zHf+JxbheQrKwLdQtCJXUgdtHEvW1ZzPhX5fV4e4JbMsYa5YnrI/mPdoYQyqJ2QbXLjKrprKuJ0yrul3ZIuG0RAUxZYc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <A1836A42088A9A47981630E4270DD704@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 078ae5cb-7a0c-4ec2-b243-08d61781a8b1
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 00:58:16.6360 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4300
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-10_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809110008
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/GsGqJw2QsOA1b9xT_ES4fGSMnNA>
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Sep 2018 00:58:24 -0000

There are two solutions being discussed here.  

The first regards how to enable a certificate to be configured for a key
in <operational> (e.g., an LDevID cert for a preexisting key).  Both
solution (A) and (C) give us this - a la RFC 8342 Section C.3.2.

The second is how to delete a "hidden key" created by a client (note here
that I'm distinguishing this case from hidden keys not created by a client,
i.e., in <operational>, which cannot be deleted).  Here's where the ideas
diverge:

  - with (A), we keep the "generate" action outside the list entry (thus
    results are in <operational>, and add a new "delete-asymmetric-key"
    action is needed.

  - with (C), the action is moved inside the list entry, thus the list
    entry node itself in <intended>, and hence can be removed from
    <intended> via a normal config operation (no special action needed).

I don't see an issue configuring certificates in either case.  As I wrote
above, both solution (A) and (C) give us this. (C) still has to handle
the case where the key is in <operational> same as (A).  With (C), it's
the 1% case, whereas with (A) it’s the 100% case.

They seem close.  For the purpose of creating a key, (C) is more
complicated.  For the purpose of deleting a key, (C) seems easier.

If the action is brought inside the list entry, then renaming it to
"generate-hidden-key" makes sense.

Kent // contributor



-----Original Message-----

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