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

Kent Watsen <kent+ietf@watsen.net> Fri, 04 October 2019 17:57 UTC

Return-Path: <0100016d97eb99fe-d6ce4ac2-7c9d-4653-833b-cb9471591e68-000000@amazonses.watsen.net>
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 D5CD51208F1 for <netconf@ietfa.amsl.com>; Fri, 4 Oct 2019 10:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 ucIg6r_0TEdU for <netconf@ietfa.amsl.com>; Fri, 4 Oct 2019 10:57:44 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF81120129 for <netconf@ietf.org>; Fri, 4 Oct 2019 10:57:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1570211863; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=6a453PNOfRi53uLo8ThLg/WUAjEeWTIjerG7wmvKNkA=; b=EAKif3g/u5rr7bzJWp/+A508Yw9lllq9cr/ToWHd0AuR5Z5eVT8Ag8vCEK9EYAsu 57bNlyn8BgBMgw9k6tBVFds4T5nxhgi8yA9gXPhQAQRyyHWapDarOWX4drt9njEGx35 MR0G9j/iI9RgjQMtR/p6XBsrYlQHa5PPn/gbT9MY=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016d97eb99fe-d6ce4ac2-7c9d-4653-833b-cb9471591e68-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_05817CF7-5984-4859-9928-832DD5143F61"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 04 Oct 2019 17:57:43 +0000
In-Reply-To: <017A9541-641B-4826-983B-7C47AFA1A3AD@akamai.com>
Cc: Randy Presuhn <randy_presuhn@alumni.stanford.edu>, "netconf@ietf.org" <netconf@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
To: "Salz, Rich" <rsalz@akamai.com>
References: <B840CB4A-3DF9-4C1B-825D-F24A72EFC90F@akamai.com> <84a2ff74-67fb-069b-a9bc-4bd4187ee1bc@alumni.stanford.edu> <017A9541-641B-4826-983B-7C47AFA1A3AD@akamai.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.10.04-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/bQdXC4b_cGNC5ewR4Q3EluLadgw>
Subject: Re: [netconf] crypto-types: why symmetric keys?
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: Fri, 04 Oct 2019 17:57:47 -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 <rsalz@akamai.com> wrote:
> 
>> What’s the use-case for needing to configure symmetric keys?
>> 
> 
>>   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)
> 
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf