Re: [netconf] ietf crypto types - permanently hidden

Martin Bjorklund <mbj@tail-f.com> Fri, 03 May 2019 07:08 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 85FF212006B for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 00:08:13 -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 nZDg3zeZzhKz for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 00:08:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3B2120044 for <netconf@ietf.org>; Fri, 3 May 2019 00:08:11 -0700 (PDT)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 98E021AE0389; Fri, 3 May 2019 09:08:09 +0200 (CEST)
Date: Fri, 03 May 2019 09:08:09 +0200 (CEST)
Message-Id: <20190503.090809.1872906124999950846.mbj@tail-f.com>
To: kent@watsen.net
Cc: rwilton@cisco.com, j.schoenwaelder@jacobs-university.de, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016a797c341a-0cde321d-e18f-4d8a-8b0b-2e89ed0ec458-000000@email.amazonses.com>
References: <20190501.230622.158012882760210627.mbj@tail-f.com> <e30aa60f31ba40e8abc9cfaeffad7802@XCH-RCD-007.cisco.com> <0100016a797c341a-0cde321d-e18f-4d8a-8b0b-2e89ed0ec458-000000@email.amazonses.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/SFEYHJlETXiX_5FsRMNDqIg0xoQ>
Subject: Re: [netconf] ietf crypto types - permanently hidden
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: Fri, 03 May 2019 07:08:14 -0000

Kent Watsen <kent@watsen.net>; wrote:
> Hi Rob,
> 
> > Why is a separate action required to create the keys? 
> > 
> > Why is the configuration to generate a hidden key not sufficient for the device to automatically allocate a key in the TPM module?
> 
> 
> I seem to be failing with words. 
> Hopefully a picture will do the trick...
> 
> 
> 
> THIS IS WHAT WE HAVE CURRENTLY
> ==============================
> 
>                          |  Client is okay with the      |  Client is NOT okay with the  |
>                          |  private key being in config  |  private key being in config  |
>                          |  w/ nacm:default-deny-all.    |  i.e., wants "hidden" key.    |
>                          |  (doc model not impacted.)    |  (doc model impacted!)        |
>                          |  (this col more important)    |  (this col less important)    |
>                          |                               |                               |


I don't think the last column is less important.  That's the TPM case, right?


> -------------------------+-------------------------------+-------------------------------+
>                          |                               |                               |
> Client is okay with      |                               |                               |
> generating the private   |  <edit-config> can be used.   |  use <install-hidden-key>     |
> key (not best practice)  |                               |                               |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+
>                          |                               |                               |
> Client is NOT okay with  |                               |                               |
> generating the private   |  Currently no solution !!!    |  use <generate-hidden-key>    |
> key (best practice)      |                               |                               |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+


For the "no solution" case, it means that the client doesn't want to
write the private key, but it wants to read it.  Why should it read it
if it never writes it?  The whole point would be to be able to
re-generate the config on another device - but this would mean that
the client would use <edit-config> to pass the key, and it would be in
the upper left cell in table above.


> PROPOSAL: move "hidden" from action names to an input parameter, and let an action gen config
> =============================================================================================
> 
>                          |  Client is okay with the      |  Client is NOT okay with the  |
>                          |  private key being in config  |  private key being in config  |
>                          |  w/ nacm:default-deny-all.    |  i.e., wants "hidden" key.    |
>                          |  (doc model not impacted.)    |  (doc model impacted!)        |
>                          |  (this col more important)    |  (this col less important)    |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+
>                          |                               |                               |
> Client is okay with      |  Either <edit-config> or      |  Use <install-key> with       |
> generating the private   |  <install-key> with input     |  input "hidden".              |
> key (not best practice)  |  NOT "hidden".                |                               |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+
>                          |                               |                               |
> Client is NOT okay with  |  Use <generate-key> with      |  Use <generate-key> with      |
> generating the private   |  with input NOT "hidden".     |  with input "hidden".         |
> key (best practice)      |                               |                               |
>                          |                               |                               |
> -------------------------+-------------------------------+-------------------------------+

An option could perhaps be to let the "generate-key" with option
"not-hidden" create the private key in <operational> (still with
nacm:default-deny-all).  To re-create the key on another device, the
client would use install-key.


/martin