Re: [netconf] built-in trust anchors

[Kent Watsen <[e-mail]>]

Hi Martin,


> On Jan 14, 2021, at 2:46 AM, Martin Björklund <[e-mail]> wrote:
> 
> 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].

Update: I did look at this draft and found the motivation unclear.


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

I think that there is a misunderstanding somewhere.  It might be helpful for me to clarify that, at a high-level: 1) the drafts only present a *configuration* model, and that 2)  it’s possible that some “config” only shows up in <operational>, when the values are “built-in”.

For the “config” that only shows in <operational>, it’s necessary to promote them to <running> in order for leafrefs to resolve.  I agree that only the “name” is needed, but we lack a mechanism to just configure a name as otherwise 1) validation would fail because "mandatory true” descendants would fail validation and 2) there’s no way to tell “apply config” process to not-delete the missing values.


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

I agree the patterns are good, but disagree that *this* come up once in awhile or, for that matter, ever before…and likely never again (at least not within my understanding).


> It seems that
> the "hidden" design already used in crypto-types can be used in this
> case, as Jürgen suggested.

Please note that the value is hidden in <operational> originally.   This is because, e.g., it is impossible to extract a private key value from a TPM.   Regardless, the net-net is that the value is “hidden” in both <operational> *and* <running> (when the asymmetric key has been copied into <running>).   To be clear, hidden private keys nodes still appear in <running> (they are *not* missing) and have the same value as appears in <operational>.


>  I don't remember this propsal from the
> previous discussion; was it discussed?

We’ve been discussing these drafts for a long time, and you know that I’ve been careful to communicate pretty much everything along the way…

Looking at the keystore draft's Change Log, I see that the “require-instance false” idea was added in -05 (June 2018) and removed in -07 (April 2019).  

As for “hidden”, the current approach arrived in crypto-types-08.  Previously, the node was a ‘union’ with "permanently-hidden” being an enumerated value.  This idea was moved into crypto-types-01 from 
keystore-06.  It was called "hardware-protected” in keystore 03-05, and “INACCESSIBLE” in keystore 01-02.

We also explored letting the private-key value be "mandatory false” somewhere along the line.  Without digging for dates, I’m sure the reason we backed out of it is because, again, it didn’t make sense to do it for a 1% use case.


K.