[Netconf] ietf-system-keychain draft module

Michal Vaško <mvasko@cesnet.cz> Tue, 02 August 2016 14:09 UTC

Return-Path: <mvasko@cesnet.cz>
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 5B2A812D623 for <netconf@ietfa.amsl.com>; Tue, 2 Aug 2016 07:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Level:
X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
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 0WoMC3pMD8Q8 for <netconf@ietfa.amsl.com>; Tue, 2 Aug 2016 07:09:19 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) by ietfa.amsl.com (Postfix) with ESMTP id 6956F12D666 for <netconf@ietf.org>; Tue, 2 Aug 2016 07:09:14 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id CDE056017B; Tue, 2 Aug 2016 16:09:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1470146952; bh=hoWpvnDxDws/4OMQ8VExRyGnrb9nLeUJRsFMwxKe71M=; h=to:date:subject:from; b=C0WFbsQJJYgyhgXQzNJS+Ldlp3sFpfY6atKKEaQ2jetVrYZbNqLhexMsuc9Gzme46 Ckm1tDQaJPdcQ0A089NrlRqXhlM2bzSZyIqVvZWxW9U7l7cAMgjpxgfKWiguw9qnXe 7CpO4g08yyzsT/4LrfH+D+Lrwk0G+A/IoYRWP2bs=
content-type: text/plain; charset="utf-8"
to: netconf@ietf.org
User-Agent: SOGoMail 2.3.13
MIME-Version: 1.0
date: Tue, 02 Aug 2016 16:09:12 +0200
message-id: <4bcf-57a0a980-25-18bcab00@35396507>
X-Forward: 2001:67c:1220:80c:c47c:d5c8:6d97:6cdf
from: Michal Vaško <mvasko@cesnet.cz>
content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/OQ8QuvU_Fy8xz8pOIESrYyXIrB4>
Subject: [Netconf] ietf-system-keychain draft module
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing 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: Tue, 02 Aug 2016 14:09:25 -0000

Hi,
I started implementing this module and I encountered some problems. I would like to know how you are planning to solve them, if they are known and being worked on, or inform you about them.

Regarding the list /keychain/private-keys/private-key, it is configurable. My guess is that the reason for this is being able to add certificate-chains to configured private keys. However, this enables the creation of instances of this list, which seems to me does not make sense and should be forbidden (or what is expected to happen in that case?). For creating new instances there are the actions generate-private-key and load-private-key, am I missing something?

As for private keys themselves, the idea probably is to keep them internally safe somewhere, so they do not appear in configuration and thus are not accidentally compromised. However, this causes major implementation issues (I know this is not considered an argument, but I believe it should not be completely neglected). Why could not be private keys part of the configuration with the NACM extension default-deny-all? My point is that other applications (using this keychain) must simply somehow get to the private key itself. Currently, the confidentiality of these keys is ensured mainly by standard file system access control. Including these keys in NETCONF datastore with default-deny-all is basically similar, but may even be considered safer than a file system. The keys could still be encrypted using a password and thus useless without it. Naturally, this password would not be part of the configuration.

Kind regards,
Michal Vasko