Re: [netconf] built-in trust anchors

Martin Björklund <mbj+ietf@4668.se> Wed, 13 January 2021 08:23 UTC

Return-Path: <mbj+ietf@4668.se>
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 2B38A3A10A7 for <netconf@ietfa.amsl.com>; Wed, 13 Jan 2021 00:23:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level:
X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=cXfdWpzl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E7z5OHRI
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 XpLDofX2mLuo for <netconf@ietfa.amsl.com>; Wed, 13 Jan 2021 00:23:29 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3843C3A10A6 for <netconf@ietf.org>; Wed, 13 Jan 2021 00:23:29 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 58DA35C0449; Wed, 13 Jan 2021 03:23:28 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 13 Jan 2021 03:23:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= LJoBc5MDUI08qU9NcgfvsjRhO55on5lsdQ/A0UnxwOc=; b=cXfdWpzlEU8ikIAu dJmWiqoFFF4S8WjH/E5vM7RTqKG+IklVpwrCxlW9nNyUt6cl0Jh/klVBL9kgZ/31 N8fnAjV1k3E4EB197guQLq4n16nEwHPkfW4X2BIuXCpQo7G9nEqeFHhVOzyNvNKp KKMhBgkJfzJdflY7p8EuZKo2qbs6rHy+7eouKm5wo/mIkWxu6Qto7kOlDQyc7hmq 97g6pEMZu5dVvq+dPJkieKZgBCgcYEQOCibR9LPe/ilkJIwka3MeIIjvsUHqpm8s s8v+Nbz/vW448sofg89fUWOp6RKPdrWPtcu3J0NRO5/grnwLZ0jxAyG/aWfvjSmQ cAIfWQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=LJoBc5MDUI08qU9NcgfvsjRhO55on5lsdQ/A0Unxw Oc=; b=E7z5OHRIg6aUfRY5AuuYl5JwjMAzZr1o1iUzOztGrjv4eyWa2Ilp3GhNG aEibuxQWPuHVh//3VBFyqN9GrpG8bn8RD5sD9vFtL/3p2Fc1sQTM925fnyytSF5D 4XWOBljWQqd/tYeDy20aC7hNLe+FVAf3x6FdYOzi7Mgsk6Xa9FwRYJYCIQDMBAci TuBEo4fK3E2Ig7/F7CVX1qprEcU+tQrdDEXI/sF6N3mSM5Cw2ig3DepibodvwIn1 3ENLuH/bCXCG5xUX6+Sq2iIbWBfkL53fijnR4cChktprw3g6xb7UB6EyXOYm3/lc bwg4kufeyDLHTr+SSJjRiEqLBfpZw==
X-ME-Sender: <xms:_63-X9fqBH__t7BSKTewYnj5sigj7vwbZ4I1Ha0GwgOm1Q2bwnAVzw> <xme:_63-X7NDP7gOlkP-T3iG08LYz5hIRSe0srsVW3e89tBA9iEp6ehgPv3Xsf3UdLP-0 NeC7PeaF5gorcx2Sxo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedukedrtddugdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepffehudffhfevleevvdejie ffudfftdehvdehteehtdetleelkeekffejtdfhtdefnecuffhomhgrihhnpehivghtfhdr ohhrghdpjhgrtghosghsqdhunhhivhgvrhhsihhthidruggvnecukfhppeduheekrdduje egrdegrddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:_63-X2j9JuQGVnN7cg85dpQZNWiNWdYNsC1blEZO8TbYXpb5j5Dtpg> <xmx:_63-X2_BCD03m4UDlmJjIz-bgnNZTqFtI15oGmECyLNiPcnDqaA9bQ> <xmx:_63-X5vaG6uk140V0-6ZSezlvwA7UqiUcN20tRqPm6SkekfP-c-OzQ> <xmx:AK7-X31fvwD8pMkmCWU_QxNxdyiXu2N-Ybcc3kGX2CXZeLxTTCqcdg>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id F14B024005A; Wed, 13 Jan 2021 03:23:26 -0500 (EST)
Date: Wed, 13 Jan 2021 09:23:25 +0100
Message-Id: <20210113.092325.468429939674786955.id@4668.se>
To: jason.sterne@nokia.com
Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <DM6PR08MB5084ED69870DF456DA8F1A509BAA0@DM6PR08MB5084.namprd08.prod.outlook.com>
References: <DM6PR08MB5084E8CF8D3D4D0E77C841CD9BAA0@DM6PR08MB5084.namprd08.prod.outlook.com> <20210112195951.oi7dlnnqpda7wavm@anna.jacobs.jacobs-university.de> <DM6PR08MB5084ED69870DF456DA8F1A509BAA0@DM6PR08MB5084.namprd08.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Exnd-Fw4osPvW58ScPwFFqgjii0>
Subject: Re: [netconf] built-in trust anchors
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: Wed, 13 Jan 2021 08:23:31 -0000

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> wrote:
> Yes - adding require-instance false would eliminate the issue about
> built-in anchors in <running>. But there are useful advantages to
> keeping require-instance true. I don't have a strong feeling though
> one way or the other.

The current text has this:

   A server MUST reject attempts to modify any aspect of built-in trust
   anchors, both the certificates themselves and the bags that contain
   them.  That these certificates are "configured" in <running> is an
   illusion, as they are strictly a read-only subset of that which must
   already exist in <operational>.

This is really weird special handling of some config in <running>,
which goes against the idea that the client(s) "own" the contents of
<running>.

It is also not clear what happens if the set of built-in trust anchors
are changed during a software upgrade.  Will they be removed from
<running> automatically?  If so, <running> may become invalid with
dangling refrences.  If they are not removed, they will be stuck
there, since a client can't remove them.

I agree that strong references are preferred in most situations, but
in this case I think a weak reference is the best solution.  It has
it's own set of problems that must be solved though, specifically what
happens if the target doesn't exist.

> But assuming we keep require-instance true then the question still
> remains of how built-in items get into <running> (and are they
> deletable, and do we only need keys in running, etc).

I think these lists have some mandatory elements, which means that you
can't just copy the keys.


/martin



> 
> Jason
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> > Sent: Tuesday, January 12, 2021 3:00 PM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
> > Cc: Netconf <netconf@ietf.org>
> > Subject: Re: [netconf] built-in trust anchors
> > 
> > Jason,
> > 
> > since the leafref typedefs are weak references that do not require
> > that the certs/keys exist (there is no 'require-instance true'), it
> > may be OK to not have the certs/keys in <running> in terms of validity
> > of the <running> datastore.
> > 
> > Oops, I had to reread RFC 7950 (section 9.9.3): if require-instance is
> > not present, it defaults to true, so my review comment about weak
> > references is incorrect, these are actually strong references and
> > hence there is the need to copy what is referenced. Setting
> > require-instance to false may resolve this (but we loose the ability
> > to catch references to certs/keys that do not exist).
> > 
> > /js
> > 
> > On Tue, Jan 12, 2021 at 07:02:04PM +0000, Sterne, Jason (Nokia -
> > CA/Ottawa)
> > wrote:
> > > Hi all,
> > >
> > > I noticed Jurgen's comment about built-in trust anchors in his YANG
> > > doctor
> > review of trust-anchors-13. I wanted to pull that out into a dedicated
> > thread/discussion here.
> > >
> > > Jurgen:
> > >
> > >
> > > - Section 3 talks about populating <running> with built-in trust
> > >
> > >   anchors.
> > >
> > >
> > >
> > >    In order for the built-in trust anchors to be referenced by
> > >
> > >    configuration, the referenced certificates MUST first be copied into
> > >
> > >    <running>.  The certificates SHOULD be copied into <running> using
> > >
> > >    the same "key" values, so that the server can bind them to the built-
> > >
> > >    in entries.
> > >
> > >
> > >
> > >   Is the idea that this copy operation is an explicit management
> > >
> > >   operation or can implementations populate <running> with this
> > >
> > >   data automatically?
> > >
> > > I suppose a server *could* populate this in running as part of a
> > > built-in
> > startup datastore in the absence of a startup datastore (i.e. as
> > contents of a
> > RFC8808 factory default). But I assume it is desirable to be able to
> > delete the
> > running copy of a built-in item. So the system would have to avoid
> > populating
> > these unless it is loading the factory default.
> > >
> > > But even if the system can populate these, we'd also want the
> > > client/user
> > to be able to explicitly populate them as well (i.e. in case they
> > delete one
> > from running, and want to add it back in to reference it).
> > >
> > > In either case (system population of running, or client population of
> > running), do we really need to put the contents of the bag or the cert
> > into
> > running?  Or is populating the list key enough since the operational
> > copy
> > shows what contents are in use for that list entry?
> > >
> > > Jason
> > 
> > > _______________________________________________
> > > netconf mailing list
> > > netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > 
> > 
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf