[netconf] 答复: built-in trust anchors

["maqiufang (A)" <[e-mail]>]

Hi, Juergen,

Apologize for my chiming in, I agree that setting require-instance as false can mitigate this issue, but cannot completely solve it.

Think differently,  we could introduce a system configuration datastore which might be implement using TPM. And it can update running with the system configuration automatically, after the system configuration has been altered as a consequence of device rebooting, inserting/removing a NIC , firmware updates as you mentioned, and so on.
In this case, the client do not have to copy the referenced certificates into <running> explicitly.
It should also be deletable, but it will be reloaded into running again if the system configuration is still present in the system.

In fact, this is exactly one of the motivation we proposed the draft (https://tools.ietf.org/html/draft-ma-netconf-with-system-01) i.e., how built-in items get into <running>. another motivation is to provide a mechanism for system configuration retrieval since not all server implementations treat the system configuration data in the same way.


Qiufang Ma


-----邮件原件-----
发件人: netconf [mailto:[e-mail]] 代表 Juergen Schoenwaelder
发送时间: 2021年1月13日 16:29
收件人: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
抄送: Netconf <[e-mail]>
主题: Re: [netconf] built-in trust anchors

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.

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 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.

/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