Re: [netconf] ietf crypto types - permanently hidden
"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 03 May 2019 11:00 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 E924412004A for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 04:00:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 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, 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 TbZavq2Mt2fK for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 04:00:18 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C49120026 for <netconf@ietf.org>; Fri, 3 May 2019 04:00:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9476; q=dns/txt; s=iport; t=1556881217; x=1558090817; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h//6vrokUNalXuBodcS2pkGemczR4RyhaHBP8UNZAIM=; b=kO0iN9BwYZTbMn+dOCl3bvNTzgAnAy8j/qAZ8jhQ5VJMCc7HKK9sYqQU 2E7OvzdhOHm1Xd32Nc6D/BTbZ/myliHDZKgUS7uBCTcLPHTRog1aahhEg AUHTKzb4h0QiE9H2EQ3/yz4UqRh6+jpzdyfyta6atE7A95dYOl87ZvrvT E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAAC1Hsxc/4MNJK1lGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGCEGmBBCgKhAaIHI0IfpdUgXsOAQEYC4QERgIXgW0jNAkOAQMBAQQBAQIBAm0cDIVKAQEBAwEBASEROgsMBAIBCBABBAEBAQICJgICAiULFQgIAQEEAQ0FCBODCIF7Dw+uF4EvijOBCycBigiBQxeBQD+BEYJdNT6CYQEBgUuDIIJYBIsQgj2EbJR0CQKCCZI8I5VGg26ILIsciUsCERWBMB84gVZwFTuCbAmCEheDTIUUhT9BMZFogSEBAQ
X-IronPort-AV: E=Sophos;i="5.60,425,1549929600"; d="scan'208";a="335294235"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 May 2019 11:00:09 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x43B086n024123 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 May 2019 11:00:08 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 May 2019 06:00:07 -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; Fri, 3 May 2019 06:00:02 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: tom petch <ietfc@btconnect.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAhrcNiw
Date: Fri, 03 May 2019 11:00:02 +0000
Message-ID: <1107e4a1b2cc4b1199a328bccbf1b42f@XCH-RCD-007.cisco.com>
References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <e30aa60f31ba40e8abc9cfaeffad7802@XCH-RCD-007.cisco.com> <20190503.084757.791827158808672980.mbj@tail-f.com> <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net>
In-Reply-To: <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net>
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.17, xch-rcd-007.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Vb3BqWnOyRI7EIaVpo_iTNHj_ZI>
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 11:00:21 -0000
Hi Tom, Thanks for the insight. Some comments inline ... > -----Original Message----- > From: tom petch <ietfc@btconnect.com> > Sent: 03 May 2019 11:48 > To: Rob Wilton (rwilton) <rwilton@cisco.com>; Martin Bjorklund <mbj@tail- > f.com> > Cc: netconf@ietf.org > Subject: Re: [netconf] ietf crypto types - permanently hidden > > ----- Original Message ----- > From: "Martin Bjorklund" <mbj@tail-f.com> > Sent: Friday, May 03, 2019 7:47 AM > > > "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote: > > > 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? > > > > This is a very good question. Why don't we have actions for > > "create-interface', "create-user" or "create-acl"? In all these cases > > we have config that a device internally parses and translates to some > > internal procedure (perhaps ifconfig, adduser, iptables etc). > > > > In a way, this case is different b/c the client needs control of > > *when* the key is generated. We cannot copy & paste some config to > > another device and expect it to work exactly the same. OTOH that > > probably is true for other things as well; if a user has been created > > in the config there might be files owned by that user stored in the > > home directory. > > > > Also, we might need the option to re-generate the key (even though the > > current version doesn't support this). But *this* could be done w/ an > > action (if we need to support it). > > > > What did I miss; what makes this case special so that it can't be > > handled like other config? > > If I configure an interface, I am providing at least part of the > information and anything that the device generates - interface name, MTU, > privacy address - I can then see and may or may not be able to change. > > When I generate a key pair, yes I want to see the public key but I have no > interest in the private key. I want the device, and it is the device not > an individual user, to be able to do things with the private key, notably > to generate a certificate for the device; I now see organisations where > every device that is attached to the network must have its own certificate > regardless of what the device is, who owns it, who is logged onto it etc. > > So generate a key pair, keep the private private, use it for a certificate, > but I will never change it, don't want to know it is, I just want it > securely hidden - and it is unlikely that the notepad, smartPhone, laptop > etc will have a TPM. > > This is the policy of the most security-conscious organisation I know, the > only one whose passwords would meet the criteria laid down in RFC, but it > has only been around for a year or so so I expect others will follow suit. This is all fine and sounds sensible to me. The public key can be published in <operational>. But why does there need to be a separate YANG action required to generate the public/private key pair on the device? Why is the configuration intent of "I want you to use a securely allocated public/private key pair" (which could be in the configuration) not sufficient? If the issue is that these keys need to persist over device restart, then I would think that the solution is for the device to securely persist these keys independently of the YANG configuration. Thanks, Rob > > Tom Petch > > > /martin > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > >
- [netconf] ietf crypto types - permanently hidden Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Balázs Lengyel
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Andy Bierman
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Andy Bierman
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Andy Bierman
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… tom petch
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Martin Bjorklund
- Re: [netconf] ietf crypto types - permanently hid… Rob Wilton (rwilton)
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Juergen Schoenwaelder
- Re: [netconf] ietf crypto types - permanently hid… Balázs Kovács
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen
- Re: [netconf] ietf crypto types - permanently hid… Kent Watsen