Re: [netconf] built-in trust anchors

[Kent Watsen <[e-mail]>]

[Top-posting as this is a response to the entire thread, sans draft-ma-netconf-with-system, which I haven’t looked at yet].

Having "instance-required false” was an idea from before, but it didn’t make sense to disable validation for the 99% use-case to enable a 1% use-case.  There will only ever be a few built-in keys/certs (typically at most just one of each, to enable bootstrapping), whereas potentially many keys/certs will be configured over time (for normal ops).

Hiding all the descendent nodes except “name” for built-in keys/certs doesn’t work because the pubkey/cert is needed in order to encrypt data that only a device can decrypt, as needed to support RMA scenarios (see https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3 <https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3> starting with the 4th paragraph).

The built-in keys/certs are envisioned to be forever; they never expire nor are affected by firmware updates.  For the example of a list of public CAs (trust anchors such as Verisign, RSA, etc.), these SHOULD be in <startup> and admins SHOULD be allowed (NACM permitting) to add/remove entries.

I agree that the “illusion” text Martin quoted is "weird special handling”, but this was the best that could be envisioned after several tries.  You might recall there were two or three other variations (inc. the "instance-required false” mentioned above) that we tried before landing on this approach.

K.


> On Jan 13, 2021, at 10:09 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> On Wed, Jan 13, 2021 at 12:26:55PM +0100, Martin Björklund wrote:
>> 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.
>> 
> 
> You will have a reference to a key that is not usable, which means you
> get runtime failures (as you would get with certs that have expired or
> other issues). Note that this is only becoming a problem if the
> firmware update renames keys/certs. If the update only ships a new
> keys/certs but keeps the names consistent, things will continue to
> work. I can't tell whether this brittleness is something to be
> concerned about or whether it falls into the usual 'things may go
> wrong after an update' bag of surprises.
> 
> /js
> 
> -- 
> 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