Re: [netconf] ietf crypto types - permanently hidden

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 02 May 2019 12:21 UTC

Return-Path: <rwilton@cisco.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 1B1EA12038D for <netconf@ietfa.amsl.com>; Thu, 2 May 2019 05:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 6HuNPZEEzQkp for <netconf@ietfa.amsl.com>; Thu, 2 May 2019 05:21:22 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B303B120110 for <netconf@ietf.org>; Thu, 2 May 2019 05:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4764; q=dns/txt; s=iport; t=1556799682; x=1558009282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7M7H1jpCrCtYgOan6aQ/gcz5336ZsoOZAj4hqSrcCi0=; b=CGLQVigeAaqEQ5m6O3OHCV3xVOJ70y/QK+7Zm5aUhIKCTCcKWxx3FJx2 U14M6DRT76hqp5kKnW+LWR1ASxmJyCOATDW4NvFvc7nZ13gcP4Y32QKi9 1w9piZYeK/y0eecMc4RH1LBfp8Y0YZdFt66DC06ttpy/dk2UaV5uN2uSb E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABX38pc/4gNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBghBpgQQoCoQGiByNB5hQgXsOAQEYC4Q?= =?us-ascii?q?ERgIXhhwjNAkOAQMBAQQBAQIBAm0cDIVKAQEBAwEBASEROgsMBAIBCA4CAQQ?= =?us-ascii?q?BAQECAiYCAgIlCxUICAIEAQ0FCIMbgXsPD61WgS+KLgaBCycBigiBQxeBQD+?= =?us-ascii?q?DbjU+gmEBAYFLgyCCWASNSYRrlG0JAoIJkjgjlTuDbYgnlGICERWBMB84gVZ?= =?us-ascii?q?wFTuCbIsShT9BMZM3gSEBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,421,1549929600"; d="scan'208";a="554320361"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 May 2019 12:21:20 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x42CLKYV023004 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 May 2019 12:21:20 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 2 May 2019 07:21:19 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 2 May 2019 07:21:19 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAL4+PiAAAVM54ADt02zAAAGzCgAAAQfJ4AABQvugADqhRSAAAgkE4AAKD/bgAABK6oAAAGYSwAABxXrgAA8jwUAAA4ykpA=
Date: Thu, 2 May 2019 12:21:19 +0000
Message-ID: <e30aa60f31ba40e8abc9cfaeffad7802@XCH-RCD-007.cisco.com>
References: <0100016a6e2130be-ee556dd0-e993-459f-be28-65fe1f74ece8-000000@email.amazonses.com> <20190430.144930.844252169549242587.mbj@tail-f.com> <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com>
In-Reply-To: <20190501.230622.158012882760210627.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/vpYXz1uJjrOJxPBHB316wzuBo9I>
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: Thu, 02 May 2019 12:21:27 -0000

Hi Martin,

> -----Original Message-----
> From: netconf <netconf-bounces@ietf.org>; On Behalf Of Martin Bjorklund
> Sent: 01 May 2019 22:06
> To: j.schoenwaelder@jacobs-university.de
> Cc: netconf@ietf.org
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> Hi,
> 
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; wrote:
> > On Tue, Apr 30, 2019 at 02:49:30PM +0200, Martin Bjorklund wrote:
> > > Kent Watsen <kent+ietf@watsen.net>; wrote:
> > > >
> > > > Correct, as I didn’t think there was consensus yet.  Perhaps there
> > > > is rough-consensus, and it may be that the only way to gauge that
> > > > is to try and see how much push back there is.
> > > >
> > > > Okay, so how about this, based on this thread, there appears to be
> > > > support to add a flag to control if a key should be “permanently
> > > > hidden” or not, in which case configuration is created.
> > >
> > > I (still) object to this.  Actions shouldn't create config.  We
> > > already have generic protcol operations to do this.  We go from a
> > > document-oriented configuration model towards a command-oriented
> > > model.  Not good.  In RESTCONF, the generic methods support things
> > > like ETags, which I suspect you don't want to replicate in this
> > > action?   Will the action support all error-options of edit-config,
> > > like rollback-on-error?
> > >
> >
> > Martin,
> >
> > do you have any proposal how to support the requirement to generate a
> > key on the device that is workable with a document-oriented
> > configuration model? Do you propose that the action/rpc returns the
> > public key information as result data that then needs to be written
> > back to the server and somehow matched to the key that is cached on
> > the device? Perhaps you have other ideas I can't think of?
> >
> > I think I would be happy to not have this special hack but then we
> > need a workable alternative. Key generation on devices is something
> > that is being used - and may be even more used in the future the more
> > we get special hardware support for storing keys.
> 
> So the current draft supports two use cases:
> 
>   1.  The client configures the private and public keys explicitly
>       (simple case).  Both keys are availible in the config and
>       operaional state.
> 
>   2.  The client asks the device to generate a "hidden" key which may
>       be a key in special TPM hardware.
> 
> For 2, the client configures the name of the key (in <running>).  Then the client
> invokes the action (in <operational>).  The device generates a new key pair
> (perhaps in tpm-hw).  In <operational>, the public key is now visible and the
> private key has the special enum "permanently-hidden".

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?

Thanks,
Rob


> 
> A device that doesn't have special hardware can still implement 2, but store the
> keys in the filesystem.  Perhaps this info needs to be visible for the client, or
> even controlled by the client.
> 
> What I object to is a third use case, where the action would modify the config
> with the generated keys.
> 
> 
> /martin
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf