Re: [netconf] ietf crypto types - permanently hidden
tom petch <ietfc@btconnect.com> Fri, 03 May 2019 11:31 UTC
Return-Path: <ietfc@btconnect.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 EC9B212008A for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 04:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 7sQ4wKauAsqq for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 04:31:42 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70109.outbound.protection.outlook.com [40.107.7.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4189D12004A for <netconf@ietf.org>; Fri, 3 May 2019 04:31:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6w5EwIcokKSxJQAEvGcUqcyYnBKNqxcRd3kpCrV9oW4=; b=Q3yI3Q6WZeyB9E1qOzCIgMGpoS72EIQb7YU46GhvhqYt5LXwWAMTQZew3Ri7C+2tK8iLLHDKgE7LFmA6v/favQ5GhcLR6GBjfV3jV1qC9csgGgfn0V7tl7jlDGnouTtSP670DX8NQFPH3vIdBolEh2kDecLLjOCGytcf7AAuIik=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB5853.eurprd07.prod.outlook.com (20.178.122.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.7; Fri, 3 May 2019 11:31:38 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Fri, 3 May 2019 11:31:38 +0000
From: tom petch <ietfc@btconnect.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AQHVAZ25vWzSND4r/0+wKWIH0SB1HQ==
Date: Fri, 03 May 2019 11:31:38 +0000
Message-ID: <01cb01d501a3$49229d80$4001a8c0@gateway.2wire.net>
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> <1107e4a1b2cc4b1199a328bccbf1b42f@XCH-RCD-007.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0378.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::30) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0ca0b893-6adf-4c86-a66c-08d6cfbae7fd
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5853;
x-ms-traffictypediagnostic: VI1PR07MB5853:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <VI1PR07MB5853EEE7180FA2EDBDC7B74AA0350@VI1PR07MB5853.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0026334A56
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(366004)(189003)(199004)(51914003)(13464003)(561944003)(81156014)(81166006)(26005)(4720700003)(6506007)(8936002)(6116002)(14454004)(53546011)(62236002)(8676002)(44716002)(14496001)(102836004)(81686011)(68736007)(386003)(5660300002)(99286004)(52116002)(3846002)(86152003)(2906002)(81816011)(76176011)(84392002)(50226002)(186003)(64756008)(66446008)(229853002)(5024004)(66476007)(6306002)(446003)(110136005)(86362001)(966005)(6486002)(478600001)(44736005)(66556008)(6436002)(1556002)(4326008)(71190400001)(316002)(45080400002)(6512007)(9686003)(66066001)(25786009)(61296003)(476003)(14444005)(486006)(73956011)(256004)(7736002)(305945005)(66946007)(53936002)(71200400001)(6246003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5853; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: MQNIGkMbI0Ieg8IZKx/VXlrtU5E3JlvMYy8AsLQJfqJw+OecNF94gjrroFMshSls1He7b4ysyMrVUwzHPZVvex7omg2uyiBfPsIeDrGySltbta6QiiirxZ/RwLAxyKuAnkLFIWRmB/qxVj3x9RPK21lGvcPWTqN7uc5Cpq3AZ+bQ2NIogocVyj5ExtP2ym2ewgot5nQzqretb+UdG9nFE5vqjR5zYB+n9N5Nj83CVl0gWzfD3lRUeGbhRvDYpAiEtaIr96VaOA0hiEfPJYGQ/FcVKAV1mPjQzBsBWMorVXOu5p67N0HOHyOOuo+q/nruvb0WRPPpIS940/cBgHLWoZpeMtFbATTeNU7CTvrnAvpTRgeZ4KPmK41viobRs3K78svA8eEJvbZ9Oo3x07XeW593vm2riNMnPkaMe0HfzF8=
Content-Type: text/plain; charset="utf-8"
Content-ID: <10A656643534A94E9CFBF8473132368B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ca0b893-6adf-4c86-a66c-08d6cfbae7fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 11:31:38.5738 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5853
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/7zOypLmuSnMUIYfsc_wTl2nS-84>
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:31:46 -0000
---- Original Message ----- From: "Rob Wilton (rwilton)" <rwilton@cisco.com> To: "tom petch" <ietfc@btconnect.com>; "Martin Bjorklund" <mbj@tail-f.com> Cc: <netconf@ietf.org> Sent: Friday, May 03, 2019 12:00 PM Subject: RE: [netconf] ietf crypto types - permanently hidden > 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? How else is the key pair going to come into existence? The device is not shipped with one (although it is the sort of the thing that a Microsoft might organise if it becomes the norm). A user (with suitable credentials) brings in his device, the organisation says 'generate key pair', and certificate, and the user is then good to go for however long they use the organisation's network, could be years; and yes, the public key, and certificate, must persist in the device across restarts but not, of course, if the hardware is replaced by fresh hardware - it is a device certificate, not a user certificate. Tom Petch > 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