Re: [netconf] ietf crypto types - permanently hidden

[Andy Bierman <[e-mail]>]

On Wed, May 1, 2019 at 5:34 PM Kent Watsen <[e-mail]> wrote:

>
> The document-oriented configuration came from a requirement identified
> at the IAB Network Management Workshop (way back when).
> It is critical for rebooting, swapping out a defective device, etc.
>
>
>
> Regarding the document-model concern, here is a line of thinking that may
> help this discussion:
>
> We recently removed the "cannot be backed-up language" because there may
> be a way for a device to backup a permanently hidden key, even when
> protected by a TPM.
>
> Specifically, a TPM (I don't know about other crypto processors) is able
> to encrypt TPM-protected keys (using yet another TPM-protected key called
> the storage root key, SRK), thus the key (albeit encrypted) CAN be backed
> up, but it CAN ONLY be restored on the device having the originating TPM.
>
> Thus, instead of using the enum "permanently-hidden", the value of the
> *encrypted* key could be safely provided.
>
> Perhaps we could model the 'private-key' value after iana-crypt-hash and
> prefix the base64-encoded binary private key value with some special (not
> legal base64) value indicating that the key is 1) encrypted and 2) can only
> be restored on the originating device.  Ideally, the prefix identifies the
> device (or, better, the crypto processor), lest there is any confusion.
>
> As for "swapping out a defective device", the above idea doesn't support
> that workflow, but I think that the inability to do a full RMA is given
> with the meaning of a "permanently-hiddden" key already and, anyone that
> creates such a key does so with that understanding.   What it does support,
> though, is the full restoration of the device after a hard-drive
> replacement (or reformat) using a standard "configuration" document, which
> seems better than what we have now with the "permanently-hidden" enum.
>
>

This requirement led directly to the ability in NETCONF to do a simple
<get-config> and
stuff the returned data into an <edit-config> or <copy-config> request.


>
> The "server created config" problem could be viewed as an access control
> problem.
> There are proprietary YANG extensions that implement this approach.
>
>
> I don't understand, can you provide examples?
>

We have a "user-write" extension that can override NACM and prevent client
access to server-created configuration.

http://www.netconfcentral.org/modules/yuma-ncx/2015-10-16#user-write.704


Andy


>
>
>
> Kent // contributor
>
>