Re: [Netconf] Mandatory local configuration in Keystore groupings

Martin Bjorklund <mbj@tail-f.com> Tue, 28 August 2018 07:06 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 A13FA130E51 for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 00:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 1lzw5C7WnqIE for <netconf@ietfa.amsl.com>; Tue, 28 Aug 2018 00:06:53 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CD75E12F1A5 for <netconf@ietf.org>; Tue, 28 Aug 2018 00:06:52 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 684C71AE0449; Tue, 28 Aug 2018 09:06:49 +0200 (CEST)
Date: Tue, 28 Aug 2018 09:06:48 +0200
Message-Id: <20180828.090648.398453385489817261.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <AD108D78-8E5D-429B-AFA9-8C84430F5186@juniper.net>
References: <28C3C2C7-22BE-4425-A26C-4A777FA68A95@juniper.net> <20180827.102118.630809612057220140.mbj@tail-f.com> <AD108D78-8E5D-429B-AFA9-8C84430F5186@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/DAhyejOg8Lc0yTLCKdDxxCo5Fq4>
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: Tue, 28 Aug 2018 07:06:54 -0000

Kent Watsen <kwatsen@juniper.net> wrote:
> 
>  
> > > BTW, all private keys should have nacm:default-deny-all.
> 
> Updated in my local copy.  Added to the "asymmetric-key-pair-grouping"
> grouping, so all downstream users inherit it as well.
> 
> 
> 
> > 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.
> 
> It wasn't so locked down before.  How about the following two changes?
> 
> 1. Updated the action's description statement:
> 
>       action generate-asymmetric-key {
>         description
>           "Requests the device to generate an asymmetric key using
>            the specified asymmetric key algorithm.  This action is
>            used to request the system the generate a key that is
>            'permanently-hidden', perhaps because it is protected
>            by a cryptographic hardware module.  The resulting
>            asymmetric key is considered operational state and
>            hence present only in <operational>.";
> 
> 2. updated the enum's description statement:
> 
>           enum "permanently-hidden" {
>             description
>              "The private key is inaccessible due to being
>               protected by the system (e.g., a cryptographic
>               hardware module).  It is not possible to 
>               configure a permanently hidden key, as a real
>               private key value must be set.  Permanently
>               hidden keys cannot be archived or backed up.";
>           }   

Ok.

> > > Regarding the name, s/hardware-protected/permanently-hidden/?
> >
> > I think this is better.
> 
> Okay, but maybe it should be just "hidden"?

Both work for me.

> >> 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.
> 
> Okay.
> 
> 
> 
> >> >> 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 the 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.
> 
> We could define a "load-asymmetric-key" action that has that behavior?

Yes; if we decide to support this use case.  What do others think?

> > 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 have to use the exact values reported in <operational>?
> 
> Hmmm, using the same value could work, but it doesn't seem intuitive
> and, from a general modelling perspective, doesn't scale e.g., what 
> if there were 100 descendants?

Exactly my point.

> A couple other options:
> 
>  a) make each leaf (algorithm, public-key, private-key) type be a
>     union having an enumerated value like "in-operational"

This feels clumsy and also doesn't really scale.

>  b) replace the three "mandatory true" with three "must" expressions
>     that assert either all or none of the leafs are set.

Better, but also has scaling issues in the general case.


> > Another design could be to have the certificates in a separate list,
> > with leafrefs (require-instance false) into the "asymmetric-key"
> > list.
> 
> Perhaps, but let's see if we can make this work first.

Ok, let's look at the alternatives:

(A)

  container keystore {
    container asymmetric-keys {
      list asymmetric-key {
        key name;

        leaf name { ... }
        leaf algorithm { ... }
        leaf public-key { ... }
        leaf private-key { ... }

        must "(algorithm and public-key and private-key)
              or not (algorithm or public-key or private-key)";

        container certificates {
          list certificate { ... }
        }
    }
  }


(B)

  container keystore {
    container asymmetric-keys {
      list asymmetric-key {
        key name;

        leaf name { ... }
        leaf algorithm { mandatory true; ... }
        leaf public-key { mandatory true; ... }
        leaf private-key { mandatory true; ... }

    }

    container certificates {
      list certificate {
        ...
        leaf key {
          leafref {
            path "../../../asymmetric-keys/asymmetric-key/name";
          }
          require-instance false;
          mandatory true;
        }
        ...
      }
    }
  }


I think model B is cleaner.




/martin