Re: [Netconf] Mandatory local configuration in Keystore groupings

Martin Bjorklund <mbj@tail-f.com> Mon, 17 September 2018 14:38 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 406C4128CF3 for <netconf@ietfa.amsl.com>; Mon, 17 Sep 2018 07:38:25 -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 VP0AyNr8MWax for <netconf@ietfa.amsl.com>; Mon, 17 Sep 2018 07:38:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BEB75127332 for <netconf@ietf.org>; Mon, 17 Sep 2018 07:38:22 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id D12611AE0311; Mon, 17 Sep 2018 16:38:19 +0200 (CEST)
Date: Mon, 17 Sep 2018 16:38:19 +0200
Message-Id: <20180917.163819.1278530557866964677.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: balazs.kovacs@ericsson.com, balazs.lengyel@ericsson.com, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <1F126D9A-775C-4590-A645-6529C3066C14@juniper.net>
References: <185C7E6D-7EF1-4FFE-9A9B-74BA7E16D946@juniper.net> <20180911.095334.2041631968993039535.mbj@tail-f.com> <1F126D9A-775C-4590-A645-6529C3066C14@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/yaXTC5GBsyfMdoymHZnbV-rRLyM>
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Sep 2018 14:38:25 -0000

Kent Watsen <kwatsen@juniper.net> wrote:
> 
> 
> >> There are two solutions being discussed here.  
> >> 
> >> The first regards how to enable a certificate to be configured for a key
> >> in <operational> (e.g., an LDevID cert for a preexisting key).  Both
> >> solution (A) and (C) give us this - a la RFC 8342 Section C.3.2.
> >> 
> >> The second is how to delete a "hidden key" created by a client (note here
> >> that I'm distinguishing this case from hidden keys not created by a client,
> >> i.e., in <operational>, which cannot be deleted).  Here's where the ideas
> >> diverge:
> >> 
> >>   - with (A), we keep the "generate" action outside the list entry (thus
> >>     results are in <operational>, and add a new "delete-asymmetric-key"
> >>     action is needed.
> >> 
> >>   - with (C), the action is moved inside the list entry, thus the list
> >>     entry node itself in <intended>, and hence can be removed from
> >>     <intended> via a normal config operation (no special action needed).
> >> 
> >> I don't see an issue configuring certificates in either case.  As I wrote
> >> above, both solution (A) and (C) give us this. (C) still has to handle
> >> the case where the key is in <operational> same as (A).  With (C), it's
> >> the 1% case, whereas with (A) it’s the 100% case.
> >
> > How can a key be in operational but not in config in (C)?  I.e., what
> > is the 1% case?
> 
> Maybe too subtle, but in my first paragraph above said "e.g., an LDevID
> cert for a preexisting key".  I'm referring to how, during manufacturing,
> a private key and an associated IDevID certificate are created and loaded
> onto the device.  This key and cert are immutable, but another cert could
> be loaded for the same key.  This is the scenario captured in the example
> in: https://tools.ietf.org/html/draft-ietf-netconf-keystore-05#section-3.2.
> (search for "tpm-protected-key").  This is the 1% case.

Ok.

> >> They seem close.  For the purpose of creating a key, (C) is more
> >> complicated.  For the purpose of deleting a key, (C) seems easier.
> >
> > For the purpose of creating a certificate (A) is more complicated.
> 
> How is that so?  Actually, it seems that (A) and (C) are identical
> in this respect, from a protocol perspective.  The only difference
> is in the backend, where it uses the RFC 8342 Section C.3.2 overlay
> behavior.

With (A), once you have generated the key, you first have to create
the config for it, then invoke the action.  With (C) (99% of) the keys
already exist in the config, so you can just invoke the action.

To summarize, A and C both get the job done.  Which one is better is
probably subjective.  I think (C) is might be easier to understand.

> > Depending on the answer above, (C) has the advantage that references
> > (leafrefs) to a key can be require instance true.  With (A) they have
> > to be require instance false, since some keys only exists in
> > operational, which means that whenever there is a reference to a key,
> > that model and code must be able to handle the case that the key
> > doesn't exist.
> 
> Even with (C), some keys can be in <operational> - the 1% case, right?
> 
> Yes, if *all* keys had a presence in <intended>, then learefs to keys
> could be "require-instance true".

Right.


/martin