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
> 
> 
>