Re: [netconf] latest update to crypto-types and keystore drafts

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 
> 
> >> 2) privileged admin copies manufacturer generated key from
> >> <operational> to <running>
> > 
> > The device could also store this key (or rather just the name) in its
> > factory configuration.
> 
> Sure, but only if it's immutable.

No I disagree.  If an admin can create it, it could be part of the
factory default config, for convenience.  A user with the right access
can delete it from the config, just as if it had been created by an
admin.

> To be clear, users are not able to
> delete the manufacturer generated key(s), at least not those use to
> support the device's cryptographic identity.

Agreed.  Deleting the name from the config doesn't wipe the hw key.

> This is true even when
> wiping the device for sale...
> 
> 
> > I don't think the public key and alg needs to go into the config.
> 
> > Or in general, if the key is configured as hidden, I think it should
> > NOT have a public key and alg in the config (can be ensured with
> > "must").  However, they must be present in the operational state.
> 
> Okay, but in thinking about going down that route, I'd rather use a
> special enum/union type values to denote the absence of these fields
> than to mark the nodes mandatory false.  Personally, I think it's
> better to duplicate the values into configuration as it does no harm
> and it makes them easier and more consistent to work with

I think it makes them more difficult to work with.  Why should I be
able to modify the public key of a hw-stored key?  It is just error
prone.

> (e.g.,
> clients need the public key in order to encrypt data destined to the
> device).  Really, I don't want any keys in <operational>

If you need the public key why is it a problem to read it from
<operational>?

> , but feel
> that we have to make an exception for the manufacturer-generated keys
> (unless, to your comment above, we could mark them as immutable in the
> configuration).  [PS: in a previous life, I used per instance metadata
> when a node was immutable.]
> 
> 
> 
> >> 3) privileged admin encrypts a well-known (secret to the organization)
> >> symmetric key using the public key from the manufacturer generated
> >> asymmetric key, and stores the result (i.e., <edit-config> into
> >> keystore.
> > 
> > Ok.  However, if the device doesn't have a hidden
> > manufacturer-supplied key from step 1 (no tpm), it would be useful if
> > the admin could install this symmetric key so that it becomes hidden.
> > But that action is no longer present in the model.
> 
> True, but it seems strange that a device would have the ability to
> store hidden keys without itself being shipped with a hidden key.

Hasn't the previous discussion shown that it is quite common to store
keys separate from the normal config?

I like the new design of this module, where all keys (but one!) are
stored encrypted.  But that one key needs to be as protected as
possible.

> We
> could add a set of RPCs to manage the life-cycle of hidden keys

Or perhaps state that the management of such keys are out of scope
(for now)?

>, but
> I'd rather steer folks to using NACM in such cases, as I don't think
> it makes sense to either have 1) persistent user-created operational
> state or 2) persistent configuration that isn't configuration.
> 
> 
> 
> > Or does this model *require* the device to have such a key?  If no tpm
> > exists, then it can exist on disk?
> 
> Not required.  For devices that don't have hidden keys, plain old NACM
> could protect the encryption-key used to protect all the other keys in
> the configuration.  The primary benefit would still be present, that
> keys subsequently generated by the device would be protected by the
> encryption key.

I think this benefit goes away if the encryption key itself it present
in clear text in the config.  In this case we could as well use NACM
to protect *all* keys.

> The downside would be that the encryption key itself,
> when generated, could not be protected in the same way.  For such
> situations, it would be recommended that this key be installed from a
> known-safe connection (i.e., via an air-gapped system).

Perhaps this is the "out-of-scope" that I mentioned above?

> >> 4) if replacing a device, load previous configuration.  Since all keys
> >> should be encrypted to the same symmetric key, it should load without
> >> error.
> > 
> > Before loading the previous config, the admin must do steps 2-3 on the
> > new device, right?
> 
> Correct.  To be more clear, all steps except (4) would occur on a
> first device and then, when an RMA is necessary, steps (1-3) would
> occur on a second device, following by step (4) to migrate the
> configuration from the first device to the second device, and then the
> remaining steps (5+) would be business as usual on the second device.
> 
> 
> 
> >> [note: one issue here with the secret symmetric key itself
> >> being loaded again, but since it was encrypted using to old device's
> >> manufacturer generated asymmetric key, the logic should be able to
> >> handle it.]
> > 
> > Hmm, can you elaborate?  It seems to me to be a problem; it needs to
> > be re-installed so that it is encrypted with the new device's public
> > key.
> 
> What is meant is that the symmetric key would be created once on the
> second device, in step (3), but because the old encrypted symmetric
> key was stored in configuration (on the first device), when loading
> the configuration here in step (4), it is as if the symmetric key is
> being created again on the second device.  But the logic on the second
> device should be able to detect this anomaly (because the key would've
> been encrypted by the first device's private key, and hence decryption
> should fail on the second device) and thus the "duplicate" symmetric
> key would be discarded.

Hmm, I still don't see how this is supposed to work.  Are you
suggesting special treatment for this list entry by the edit-config /
copy-config operations?  I strongly object to such a hack, but perhaps
you meant something else?

> >> Runtime:
> >> 5) whenever a regular admin wishes to use a new key, they call the
> >> generate-symmetric-key or generate-asymmetric-key RPC, requesting the
> >> device to generate a key for them, encrypting the result using the
> >> secret organization key.
> >> 6) The RPC output returns the key value (encrypted).
> >> 7) The regular admin uses e.g., <edit-config> to store the key into
> >> <running>.
> >> 
> >> 
> >> Use cases: 
> >>  0: normal (just NACM-protected) keys:  supported.
> >>  1: manufacturer-generated permanently hidden keys: supported.
> >>  2: device-generated keys: supported.
> >>  3: device-generated keys in config: supported
> >>  4: permanently hidden keys: not recommended nor directly
> >>     supported, but one could always encrypt a key with the
> >>     device's public key, thus generating a key that only the
> >>     device can decrypt, and hence effectively permenently
> >>     hidden.
> >> 
> >> 
> >> Please let me know soon if you object to any aspect of this or,
> >> better, support it, as I need to update the remaining drafts to
> >> reflect these changes at some point soon.
> > 
> > Also, if we go this route, this draft (keystore) needs more text, and
> > also explain the use cases described above.
> 
> Agreed.  I also never documented the "generate-symmetric-key" and
> "generate-asymmetric-key" RPCs...
> 
> Regarding "going this route", your response thus far seems to be on
> the level so, would it be fair to say that you're leaning towards
> thinking that it might be okay?

Yes I think this looks promising!

> > Then there are some details, e.g. why do we have 
> > 
> >    identity asymmetric-key-algorithm {
> >      description
> >        "Base identity from which all asymmetric key
> >         encryption Algorithm.";
> >    }
> > 
> > vs
> > 
> >    identity encryption-algorithm {
> >      description
> >        "A base identity for encryption algorithm.";
> >    }
> > 
> > Why isn't the latter called "symmetric-key-algorithm"?
> 
> 
> These identities (now enumerations) are coming from the crypto-types
> module in a section maintained by my co-author from Huawei who has
> even more crypto-clue than I.  My guess is that this is what they're
> called in IANA registries for historical reasons.

Ok, but you agree that "symmetric-key-algorithm" would be better,
unless there's some strong historical reason for keeping
"encryption-algorithm"?



/martin