Re: [netconf] built-in trust anchors

Martin Björklund <mbj+ietf@4668.se> Thu, 14 January 2021 17:26 UTC

Return-Path: <mbj+ietf@4668.se>
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 8CF313A13E8 for <netconf@ietfa.amsl.com>; Thu, 14 Jan 2021 09:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level:
X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=gJICvZLX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bznJowhx
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 1PspkaqALhnl for <netconf@ietfa.amsl.com>; Thu, 14 Jan 2021 09:26:02 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0A23A15FD for <netconf@ietf.org>; Thu, 14 Jan 2021 09:25:57 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D2F785C0178; Thu, 14 Jan 2021 12:25:54 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 14 Jan 2021 12:25:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= zcS1z20SzAarw0NimkdZUV3wWTmRp77zwwhuBhhjE7Q=; b=gJICvZLXF7YcNVDC kF5/lmour8hFzVdhXvcQFylnZNS5O8xLwZowQSgewqyteY+ZxZ1ogOlFjlzGN5UM X0qos5IDgSlNOlXXwG3UAT+weNeQte5lbDl2vHbPNkl4/k38TGhXs2/YY/oAhsRY dzxNxwDaszauK3YeKn3h8zPfUDTB3zeg5MiytrATHq3PtD48I+Xo0p0r52Day7xp OD4lW6jc4ioJkmsjCQjTMFhD4wzNd/0LjbeHnWVcxv6KrWIri0FUFcDrdef2bjfn AoUL7VLp8RBWrxBpcnQ5EwxgHMqBwQs9Sx8aWFqwozN1amBFQUhm5wee20KDUdaX bp+TqQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=zcS1z20SzAarw0NimkdZUV3wWTmRp77zwwhuBhhjE 7Q=; b=bznJowhxyhsVpHUZgG8nDfqnfBU2aajM4osICEdZFmDb/2oTDQpXMS052 yne+dG9+myiPtiElmjxmjrP6osLVloqXiRG90/4IBKkUkfx709eH4q2a2knlT5or pVXGWBbTh4qZc4FIGG5cZIlU3nhSVrUcAGlTlwz58DFRjoAamD/F18TQsEbwAzFj KOZG8juWtw99VLx8t5jdSZBw3HqHo+u4349HhhDJgCs4KRCzWbnOkBcVNMeRNRdn K6y4cMM8nXUKwQcVzYyA9K+7QKETqOihtjJjyyM8zE4J5H1uYSICmoGApRAPcLm2 9zVVjwZlamq3zkMhg38Anxu3UaVEg==
X-ME-Sender: <xms:oH4AYBOU5O75t10z_oJIyFMSS1DXmajOYYBoMDjGMTvg8Jz7eBInhg> <xme:oH4AYD861lco9deXh_wcDXzbMyWWMDBut5jF-kYIAdCpuOuIyyYec1XfN32n5Gha8 CkFiXwlEuZZ_nUR7ug>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtddtgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesthgsre dtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdoihgv thhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeefheekgfdukeefheeihefhke egvdffheetvefgfeefgefhvdefueeluddvvdfgheenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeduheekrddujeegrdegrddvudehnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:oH4AYAS__ykLPKRd6tDHElwzz4-Rc8mvqmTQSlDsdzAYxFUY_kSf1w> <xmx:oH4AYNtYFXzyQCYRuLLXNVWmy2MakBzg69_1mG4N0YoVpTpOtB63Jg> <xmx:oH4AYJdbExPfH4mLl8kmXzPaxjjsXo14KO3b-Z8oCjCXkBYID0cQtQ> <xmx:on4AYPrVqVwg2_RKkPIlCQBXdqRZLUXBLKVpmtsbP1nTpdCnyDFI3A>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 21B1B1080057; Thu, 14 Jan 2021 12:25:52 -0500 (EST)
Date: Thu, 14 Jan 2021 18:25:50 +0100 (CET)
Message-Id: <20210114.182550.2075205444128224956.id@4668.se>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <0100017701b91b90-5b4fac25-1818-41c2-be81-4f57296fe9d2-000000@email.amazonses.com>
References: <01000176fc95b165-e1e7254b-3895-4267-8470-854552276315-000000@email.amazonses.com> <20210114.084621.1561500589637511150.id@4668.se> <0100017701b91b90-5b4fac25-1818-41c2-be81-4f57296fe9d2-000000@email.amazonses.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/MHx25N20JRslP8I4Bi5AEvp7QC8>
Subject: Re: [netconf] built-in trust anchors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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: Thu, 14 Jan 2021 17:26:06 -0000

Kent Watsen <kent+ietf@watsen.net> wrote:
> Hi Martin,
> 
> 
> > On Jan 14, 2021, at 2:46 AM, Martin Björklund <mbj+ietf@4668.se>
> > wrote:
> > 
> > Kent Watsen <kent+ietf@watsen.net> wrote:
> >> [Top-posting as this is a response to the entire thread, sans
> >> draft-ma-netconf-with-system, which I haven’t looked at yet].
> 
> Update: I did look at this draft and found the motivation unclear.
> 
> 
> >> Having "instance-required false” was an idea from before, but it
> >> didn’t make sense to disable validation for the 99% use-case to enable
> >> a 1% use-case.  There will only ever be a few built-in keys/certs
> >> (typically at most just one of each, to enable bootstrapping), whereas
> >> potentially many keys/certs will be configured over time (for normal
> >> ops).
> > 
> > Ok.
> > 
> >> Hiding all the descendent nodes except “name” for built-in keys/certs
> >> doesn’t work because the pubkey/cert is needed in order to encrypt
> >> data that only a device can decrypt
> > 
> > I don't understand this.  The descendent nodes would not be present in
> > 'running', but they would be present in <operational> (b/c they are
> > present in the firmware).
> 
> I think that there is a misunderstanding somewhere.  It might be
> helpful for me to clarify that, at a high-level: 1) the drafts only
> present a *configuration* model, and that 2) it’s possible that some
> “config” only shows up in <operational>, when the values are
> “built-in”.
> 
> For the “config” that only shows in <operational>, it’s necessary to
> promote them to <running> in order for leafrefs to resolve.  I agree
> that only the “name” is needed, but we lack a mechanism to just
> configure a name as otherwise 1) validation would fail because
> "mandatory true” descendants would fail validation and 2) there’s no
> way to tell “apply config” process to not-delete the missing values.

It can be done by doing something similar to "hidden", here's a sketch
of the idea:

  list certificate-bag {
    key name;
    leaf name { ... }
    choice type {
      case inline {
        list certificate { ... }
      }
      case built-in {
        leaf built-in { type empty; }
      }
    }
  }


> >> , as needed to support RMA
> >> scenarios (see
> >> https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3
> >> <https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3>
> >> starting with the 4th paragraph).
> >> 
> >> The built-in keys/certs are envisioned to be forever; they never
> >> expire nor are affected by firmware updates.
> > 
> > :)
> > 
> >> For the example of a
> >> list of public CAs (trust anchors such as Verisign, RSA, etc.), these
> >> SHOULD be in <startup> and admins SHOULD be allowed (NACM permitting)
> >> to add/remove entries.
> >> 
> >> I agree that the “illusion” text Martin quoted is "weird special
> >> handling”, but this was the best that could be envisioned after
> >> several tries.  You might recall there were two or three other
> >> variations (inc. the "instance-required false” mentioned above) that
> >> we tried before landing on this approach.
> > 
> > Since this problem comes up every now and then, it would be good with
> > a design pattern that can work in other cases as well.  
> 
> I agree the patterns are good, but disagree that *this* come up once
> in awhile or, for that matter, ever before…and likely never again (at
> least not within my understanding).
> 
> 
> > It seems that
> > the "hidden" design already used in crypto-types can be used in this
> > case, as Jürgen suggested.
> 
> Please note that the value is hidden in <operational> originally.
> This is because, e.g., it is impossible to extract a private key value
> from a TPM.  Regardless, the net-net is that the value is “hidden” in
> both <operational> *and* <running> (when the asymmetric key has been
> copied into <running>).  To be clear, hidden private keys nodes still
> appear in <running> (they are *not* missing) and have the same value
> as appears in <operational>.

Yes.

> >  I don't remember this propsal from the
> > previous discussion; was it discussed?
> 
> We’ve been discussing these drafts for a long time, and you know that
> I’ve been careful to communicate pretty much everything along the way…

Absolutely, this is much appreciated!

> Looking at the keystore draft's Change Log, I see that the
> “require-instance false” idea was added in -05 (June 2018) and removed
> in -07 (April 2019).
> 
> As for “hidden”, the current approach arrived in crypto-types-08.
> Previously, the node was a ‘union’ with "permanently-hidden” being an
> enumerated value.  This idea was moved into crypto-types-01 from
> keystore-06.  It was called "hardware-protected” in keystore 03-05,
> and “INACCESSIBLE” in keystore 01-02.
> 
> We also explored letting the private-key value be "mandatory false”
> somewhere along the line.  Without digging for dates, I’m sure the
> reason we backed out of it is because, again, it didn’t make sense to
> do it for a 1% use case.

I much prefer Jürgen's proposal than haveing special rules for some
nodes in <running>.  Especially if it falls into this "1%" bucket.


/martin