Subject: [netconf] crypto-types: why symmetric keys?

From: "Salz, Rich" <[email-masked]>
Date: Fri, 4 Oct 2019 13:37:26 +0000

What’s the use-case for needing to configure symmetric keys?

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 4 Oct 2019 09:43:12 -0700

Hi -

> What’s the use-case for needing to configure symmetric keys?

Provisioning SNMPv3 USM comes to mind.

Randy

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 4 Oct 2019 16:58:52 +0000

>    Provisioning SNMPv3 USM comes to mind.
  
Thanks.

If we are going to partition crypto-types into smaller pieces, then it seems we have three things now:
	TLS (https servers, certs and keys for RSA and ECDSA)
	SSH ("raw" public and private keys)
	SNMP (symmetric keys)

---

From: Kent Watsen <[email-masked]>
Date: Fri, 4 Oct 2019 17:57:43 +0000

Hi Rich,

The introduction of the symmetric-keys to the model was primarily to resolve an issue for how to support device-generated keys, whereby the keys would subsequently be present in the device's configuration and referenced by other configuration.  The current `generate-symmetric-key` and `generate-asymmetric-key` 'action' statements are the 4th iteration for an approach for how to do this.  The idea, in order to maintain the security of the key (i.e., so it cannot be known even to the administrator using it), is to encrypt the private or symmetric key returned from the 'action' statement.  The administrator then turns around and configures the [encrypted] key back onto the device.  Use of a symmetric key to encrypt keys has been shown as a being helpful to supported RMA (device swaps), discussed here: https://mailarchive.ietf.org/arch/msg/netconf/pn0LucnWx3Xz0rfBRqB31BVg-Bk <https://mailarchive.ietf.org/arch/msg/netconf/pn0LucnWx3Xz0rfBRqB31BVg-Bk>.

That said, Henk Birkholz (CC-ed) pointed out in Montreal that the current TLS model on supports X.509 certificates, but it needs to also support pre-shared keys (PSKs) and raw public keys.  Henk has already added PSK and RPK to an unpublished version of the Truststore (see the trust-anchors draft).  That being the case, it makes sense that the symmetric keys in Keystore could be used as/for the PSKs in TLS.  Is so, then please add this use case to the list.

Kent

> On Oct 4, 2019, at 12:58 PM, Salz, Rich <[email-masked]> wrote:
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 4 Oct 2019 18:06:35 +0000

Thanks for the clarification.

I continue to urge development of small models that meet most (*not all*) needs of service configuration.  TLS’s PSK keys need to be shared by the server and client(s), so I am not sure about the utility of “so not even the administrator knows it”  I am ignorant if PSK’s are actually needed for enterprise use of TLS.

---

From: tom petch <[email-masked]>
Date: Tue, 8 Oct 2019 10:06:35 +0000

----- Original Message -----
From: "Salz, Rich" <[email-masked]>
Sent: Friday, October 04, 2019 7:06 PM

> I continue to urge development of small models that meet most (*not
all*) needs of service configuration.  TLS’s PSK keys need to be shared
by the server and client(s), so I am not sure about the utility of “so
not even the administrator knows it”  I am ignorant if PSK’s are
actually needed for enterprise use of TLS.

Rich

From my (limited) experience of Enterprise, and assuming that PSK is
Pre-Shared Key, a string of unspecifed length, I see SSH used,
mostly, for Systems and Network Management with HTTPS used, mostly, for
operational systems, user access, with two-factor authentication where
user authentication  is needed.  Almost all user access is to a web
server with little or no raw e-mail, file transfer or such like
protocols.

I see device - not user - certificates used to secure VPN access.

I do also see configuration of PSK when a new departmental server comes
along, and is configured with user-id and one-time passwords which are
e-mailed out to the users; sometimes the PSK is a four-digit pin.
(Real-world security as opposed to IETF standards security:-)

One other thought.  The Enterprises I know are just migrating from
Windows 7 to Windows 10 since support for the former expires this year.
Over the past year or so, they have migrated from TLS 1.0 to TLS1.2.
This suggests to me that TLS 1.3, which is rather different, for PSK and
everything else, is some way off and that our focus should be on TLS 1.2
but I do not know if that would get past a Secuirty AD - the YANG
boilerplate now mandates TLS 1.3.

Tom Petch

------------------------------------------------------------------------
--------