Re: [netconf] built-in trust anchors

[Martin Björklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> wrote:
> After sleeping over it, I think a device should ship with the keys
> listed in whatever is the equivalent of the factory default, i.e.,
> they are initially in <running>. Deleting them should be possible with
> the effect that no config can refer to these keys anymore (assuming
> strong references). Putting the keys back into running makes them
> available for config again.

This could work, but see below.

> I would be in favour to just have the names in runnning, not the
> key/cert details. This avoids issues with entries that do not match,
> and this then resembles hidden keys, for which details are also not
> known in <running>. In fact, <hidden> keys likely have the same
> property that they exist in the system (or a TPM), i.e., they are not
> config that can be arbitrary changed. I would assume that the same
> rules apply, if you delete a hidden key from <running>, it can't be
> referenced and used anymore. Perhaps the discussion in the I-D should
> be expanded to cover hidden keys as well.

I like the symmetry w/ hidden keys.  I assume that these entries would
be explicitly marked in the config as being "built-in" or "hidden".

> I also expect that these special keys may be part of the firmware,
> i.e., they may change with firmware updates. This can lead to stale
> special keys that do not exist anymore in the firmware and new keys
> that exist in the firmware but must be (manually) added to <running>
> in order to use them.

So then the question is what happens if a key is removed from the
firmware, but it exists (with just the name) in the config, and some
part of the config reference it?

I think that this leads to the same problem as a weak leafref would
do, so either solution would work.


/martin


> 
> /js
> 
> On Tue, Jan 12, 2021 at 10:59:28PM +0000, Sterne, Jason (Nokia - CA/Ottawa) 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.
> > 
> > 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).
> > 
> > Jason
> > 
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder <[e-mail]>
> > > Sent: Tuesday, January 12, 2021 3:00 PM
> > > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> > > Cc: Netconf <[e-mail]>
> > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > 
> > > 
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf