Re: [netconf] built-in trust anchors

[tom petch <[e-mail]>]

From: netconf <[e-mail]> on behalf of Kent Watsen <[e-mail]>
Sent: 13 January 2021 16:30
[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).

<tp>
depends where you are.  For me, the great advance in Internet security was when Microsoft built in the certificates I needed to access sites securely, in the shrink-wrapped software.  I do not know how many there are but it is now rare for me to need to add one.

By contrast other certificates are ephemeral, used for a session and then discarded.

I can guess the model you have in mind but suspect that it is not the common one when looking at security across the Internet as a whole.

Tom Petch

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 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]<mailto:[e-mail]>> wrote:

On Wed, Jan 13, 2021 at 12:26:55PM +0100, Martin Björklund wrote:
Juergen Schoenwaelder <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf