Re: [Netconf] Mandatory local configuration in Keystore groupings
Martin Bjorklund <mbj@tail-f.com> Mon, 27 August 2018 08:21 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 86798128C65 for <netconf@ietfa.amsl.com>; Mon, 27 Aug 2018 01:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 LCRvq16C2Y-W for <netconf@ietfa.amsl.com>; Mon, 27 Aug 2018 01:21:22 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C30AE130E7B for <netconf@ietf.org>; Mon, 27 Aug 2018 01:21:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 511011AE0312; Mon, 27 Aug 2018 10:21:19 +0200 (CEST)
Date: Mon, 27 Aug 2018 10:21:18 +0200
Message-Id: <20180827.102118.630809612057220140.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: balazs.lengyel@ericsson.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <28C3C2C7-22BE-4425-A26C-4A777FA68A95@juniper.net>
References: <AF6441A6-CFE4-470C-991D-AF9ACE46C648@juniper.net> <20180822.102452.1792964591006331128.mbj@tail-f.com> <28C3C2C7-22BE-4425-A26C-4A777FA68A95@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/o18LIaokrDnAUj5GezB_mftOAOs>
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 27 Aug 2018 08:21:24 -0000
Kent Watsen <kwatsen@juniper.net> wrote: > > > >> I don't believe there is a security issue. NACM or equivalent can > >> be used in either case. > > > > Yes, but it may be desirable to keep all keys in a single place, > > instead of scattered around. But I'm ok with using a feature. > > Yes, let's go with the feature. I've added it to my local copy. > > > BTW, all private keys should have nacm:default-deny-all. > > I'd agree if we were only talking about backup/restore operations, > which match the definition of a "recovery session", but here we're > trying to support workflows that would occur during normal operation > of the device, by administrators having sufficient permission. The > Security Considerations section provides guidance on this too. nacm:default-deny-all means that in order to access this node, the user needs an explicit rule in NACM that covers this node. It does _not_ mean that only a "recovery session" can access the node. This statement is used in e.g. ietf-system to protect radius shared secrets, and in ietf-snmp to protect community strings and USM keys. > >> That said, the current action has no input parameter to direct > >> the device to use an HSM or filesystem. Perhaps there is a > >> need for a feature indicating the device has an HSM? > > > > I think that this is an implementation choice that doesn't have > > to be visible to the operator. I.e., if there's special hw it > > will be used, else a filesystem (or something else) will be used. > > No, what I meant was that generate-asymmetric-key could take an > input parameter (enum?), protected by a feature, that the client > could use to indicate the key needs to be permanently hidden, or > define the entire RPC to have that behavior? I think that the operation "generate-asymmetric-key" only affects "permanently-hidden" keys, doesn't it? If the client wants visible keys, it will configure them in the config datastores. > Regarding the name, s/hardware-protected/permanently-hidden/? I think this is better. > > No, this won't work. Note the text you quoted: > > > > Otherwise [no prefix], a feature with the matching > > name MUST be defined in the current module or an included submodule. > > > > the current module is the module that has the if-feature statement, > > i.e., ietf-keystore. > > okay. I was hoping that is could be the module using the grouping. > > > > But I think a global feature is fine. Models can always add their own > > additional if-fetaure expressions via refinement. > > True. > > > > >> > 1) Is the enum "hardware-protected" really a good name in this > >> > case? > >> > >> As opposed to what? > > > > In my use case I would implement "generate-asymmetric-key" and it > > would create the keys in the file system, and the public key would be > > available in <operational>. I don't want to expose the private key in > > <operational>, so I would have to return "hardware-protected". But it > > isn't hardware protected... > > Would "permanently-hidden" be better? > > > > <snip/> > > I think this is the real issue. So it might be that my use case of > > not wanting to expose private keys at all even if there's no TPM is > > explicitly not supported. I.e., unless there's special hw present, > > all private keys MUST be exposed (but NACM-protected). > > Now you have me second-guessing this. Maybe a device, without special > hardware, could present the illusion of a permanently-hidden private > key - it's completely inaccessible from the device's supported > interfaces, though actually present on the filesystem. This is what I would like to support. > >> Unsure what you mean. Currently all these values are configurable. > >> Or are you trying to find a way to only "configure" them in > >> <operational>? > > > > Yes, *if* my use case of not exposing the private keys is supported, > > then it would be useful to be able to generate the keys off-box, and > > install them into <operational>. > > Hmmm, sounds like *configuration*, not something goes into <operational>. > > And, even if you did, that doesn't mean the keys are permanently-hidden. > I suppose the model could let them client set that parameter as well, > but it somewhat defeats to goal of *never* having the private key exposed, > not even as a once in a lifetime kind of thing. That’s just my opinion, > we should ask for more opinions if you're not convinced. I'm not convinced either way, actually ;-) It would be good to hear other opinions as well. > >> The idea is to use the approach that was taken with the I2RS topology > >> model, using require-instance false. Specifically, the > >> "local-or-keystore-asymmetric-key-with-certs-grouping" has leaf > >> "reference" of type "asymmetric-key-ref": > >> > >> <snip/> > >> > >> Makes sense? > > > > Isn't the idea that once I have a certificate, I will write it into > > /keystore/asymmetric-keys/asymmetric-key/certificates/certificate? > > > > My question is how this is supposed to work for a hardware-protected > > key that only exists in <operational>? > > Sorry, I think my example was wrong. A better example might be the > interfaces example in Section C.3.2 in RFC 8342 [1], where the > configs overlay each other (e.g., matching keys). > > For a hardware-protected key, the "asymmetric-key" (in keystore) still > appears in <operational> with an exposed "key" name, the "private-key" > value is set to "hardware-protected". So the thinking is that a similar > path can be constructed in <intended>, while only adding/configuring the > certificates. This is what I would expect as well, but the model is not quite designed for this currently. For example, suppose I generate a HSM-protected key with "generate-asymmetric-key". It is then present in <operational>, with a public key etc. Now I want to configure a certification for this key, so I have to create an entry in the "asymmetric-key" list, where I have to set both the private-key and public-key leafs (they are both mandatory); so I assume I jhave to use the exact values reported in <operational>? Another design could be to have the certificates in a separate list, with leafrefs (require-instance false) into the "asymmetric-key" list. /martin > Actually, check out the example in keystore-05 at the end of page 7: > > <asymmetric-key or:origin="or:system"> <--- system generated > <name>tpm-protected-key</name> > <algorithm>ct:rsa2048</algorithm> > <private-key>hardware-protected</private-key> <--- hw protected > <public-key>base64encodedvalue==</public-key> > <certificates> > <certificate> > <name>builtin-idevid-cert</name> > <cert>base64encodedvalue==</cert> > </certificate> > <certificate or:origin="or:intended"> <--- configured cert > <name>my-ldevid-cert</name> > <cert>base64encodedvalue==</cert> > </certificate> > </certificates> > </asymmetric-key> > > > > Kent // contributor > > >
- [Netconf] Mandatory local configuration in Keysto… Balazs Lengyel
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Martin Bjorklund
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen
- Re: [Netconf] Mandatory local configuration in Ke… Balázs Kovács
- Re: [Netconf] Mandatory local configuration in Ke… Kent Watsen