Re: [netconf] ietf crypto types - permanently hidden
tom petch <ietfc@btconnect.com> Fri, 03 May 2019 10:48 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 846EE120026 for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 03:48:28 -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 IOBcJbkGM1nq for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 03:48:26 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20091.outbound.protection.outlook.com [40.107.2.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCF71200B1 for <netconf@ietf.org>; Fri, 3 May 2019 03:48:25 -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=iwPvxj55rw0Sr88hWQ8sR/xxSbkcYAczg3tiiR++aKo=; b=KDDW6LUQYuGm1F3Ep3srolLhqtO/tOKFx8xkMR4fVdos9Imq45VQYHgOY8hIpcmCtxActnfASLmnFR03bb3tD+sMZaGlV6RcArWg0aJ9knnK2QMklFu5DtW45Wcqa+3Q4KukKYJTKJsPXrXXGipzuNM4ZgTuqgvSXyk0OsnLj54=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB5406.eurprd07.prod.outlook.com (20.178.14.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.6; Fri, 3 May 2019 10:48:23 +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 10:48:23 +0000
From: tom petch <ietfc@btconnect.com>
To: "rwilton@cisco.com" <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 10:48:20 +0000
Message-ID: <016d01d5019d$3c85e9c0$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>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0366.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::18) 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: 899478bd-9b4a-4f61-4e2e-08d6cfb4db5b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5406;
x-ms-traffictypediagnostic: VI1PR07MB5406:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <VI1PR07MB54063A6D522006725F7CCDB3A0350@VI1PR07MB5406.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0026334A56
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(39860400002)(346002)(136003)(189003)(199004)(13464003)(2501003)(61296003)(66946007)(81166006)(81156014)(8676002)(7736002)(62236002)(6306002)(73956011)(305945005)(50226002)(8936002)(66446008)(64756008)(66556008)(26005)(256004)(14444005)(5024004)(186003)(66066001)(102836004)(486006)(6436002)(446003)(53546011)(6506007)(476003)(386003)(44736005)(6486002)(14454004)(86362001)(86152003)(66476007)(561944003)(71200400001)(71190400001)(5660300002)(1556002)(229853002)(53936002)(478600001)(14496001)(4720700003)(4326008)(6116002)(3846002)(44716002)(6512007)(9686003)(6246003)(966005)(25786009)(68736007)(99286004)(316002)(52116002)(76176011)(81686011)(2906002)(81816011)(84392002)(110136005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5406; 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: 4xj0HfKDc+WI38GLYDyBQs7RTWn1SOvfWjV+/3ocKysONXVmaiae7w2BkC3mr7dXyOEP0SFr74/j1Z6CQfrG42kd68VIKhIEDsOJXQiRJnNPJov8/a9PWvRiTO796QPzqRUbVm2PyxgM4FIkh/VRqwpjhGUEC9bLNczHZX1q55RApf7KyS2CUyZnMGpLJDliqNMevU3g6AGc1uNVGcWVUtMsrGRFZo43qtaPnPipCUfmelpt+TBk4FLY/hTl/PKXeQI/LubWLKNvh3bcYxYpQGU0chGScdGLCW7bbsRwfwBQLx6P43sUrY+1CMwdPndyQakf/U+N2WZu10MHPeo3dK6XFti+xZoqur4UEdMExi+xfliquPa8kNX8oPsKRpQ0ZzkC8LS0Dfra8QE64LcKxgQrfUNLmYt/t9Tsu3NFUOQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <742607CBE430154CB64606072BC1C925@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 899478bd-9b4a-4f61-4e2e-08d6cfb4db5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 10:48:20.3429 (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: VI1PR07MB5406
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-5XXe3XAkSJgdm7tLaBhH9h4tl0>
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 10:48:29 -0000
----- 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. 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