Re: [netconf] built-in trust anchors

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

Kent Watsen <[e-mail]> wrote:
> [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).

Ok.

> 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

I don't understand this.  The descendent nodes would not be present in
'running', but they would be present in <operational> (b/c they are
present in the firmware).

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

Since this problem comes up every now and then, it would be good with
a design pattern that can work in other cases as well.  It seems that
the "hidden" design already used in crypto-types can be used in this
case, as Jürgen suggested.  I don't remember this propsal from the
previous discussion; was it discussed?



/martin


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