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

Martin Bjorklund <mbj@tail-f.com> Thu, 27 June 2019 15:30 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10C91200F8 for <netconf@ietfa.amsl.com>; Thu, 27 Jun 2019 08:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6O42e7gz5W3 for <netconf@ietfa.amsl.com>; Thu, 27 Jun 2019 08:30:14 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A12F12010F for <netconf@ietf.org>; Thu, 27 Jun 2019 08:30:14 -0700 (PDT)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B6E71AE02F0; Thu, 27 Jun 2019 17:30:12 +0200 (CEST)
Date: Thu, 27 Jun 2019 17:30:12 +0200 (CEST)
Message-Id: <20190627.173012.789366833379165040.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016b962706ee-c3b245b6-a9ad-45cb-a7a2-b9fe44dd33c3-000000@email.amazonses.com>
References: <0100016b68794a39-0d934910-4b4b-4801-8d56-27f678081e93-000000@email.amazonses.com> <20190626.105608.121899679021225720.mbj@tail-f.com> <0100016b962706ee-c3b245b6-a9ad-45cb-a7a2-b9fe44dd33c3-000000@email.amazonses.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/zeKaYK1qvemdbEuO3-XhKmMS2yo>
Subject: Re: [netconf] latest update to crypto-types and keystore drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 15:30:18 -0000

Kent Watsen <kent+ietf@watsen.net>; 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