IETF Logo Mail Archive

Re: [netconf] ietf crypto types - permanently hidden

Balázs Lengyel <balazs.lengyel@ericsson.com> Fri, 05 April 2019 14:53 UTC

Return-Path: <balazs.lengyel@ericsson.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 D9C43120482 for <netconf@ietfa.amsl.com>; Fri, 5 Apr 2019 07:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level:
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ikl6HYOOAe4H for <netconf@ietfa.amsl.com>; Fri, 5 Apr 2019 07:53:57 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40056.outbound.protection.outlook.com [40.107.4.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4DE12046B for <netconf@ietf.org>; Fri, 5 Apr 2019 07:53:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=poxMd+DKzEfZx0cPP2u+Cvfp4FksJLKsAhhM33gChH8=; b=P8WeQBYq6AvzfAPX4Fzhbbu04Xs013BLVgPgHNBFSQkW1n0etAIWzf32qREm0gIzt3LldymyiueRpNFHDc1Rf8JCzyssz3Q25ZICCbnGDokzC8Fg9hT1k7Nxbt6+pgTeLF7cnDQzXaZpUXsNL9gOczJpA6mpYnlwZGd9DGtdZt8=
Received: from HE1PR0701MB2508.eurprd07.prod.outlook.com (10.168.129.10) by HE1PR0701MB2092.eurprd07.prod.outlook.com (10.168.30.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Fri, 5 Apr 2019 14:53:48 +0000
Received: from HE1PR0701MB2508.eurprd07.prod.outlook.com ([fe80::20ca:9699:6d54:1543]) by HE1PR0701MB2508.eurprd07.prod.outlook.com ([fe80::20ca:9699:6d54:1543%7]) with mapi id 15.20.1771.006; Fri, 5 Apr 2019 14:53:48 +0000
From: Balázs Lengyel <balazs.lengyel@ericsson.com>
To: Martin Bjorklund <mbj@tail-f.com>, "ietfc@btconnect.com" <ietfc@btconnect.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AQHU679f1WNMIVsqeEG2PDBEdPRHrw==
Date: Fri, 05 Apr 2019 14:53:47 +0000
Message-ID: <413d5725-9c27-e50b-2622-1b0e2f35cdb1@ericsson.com>
References: <20190404164929.fsfga7s4izn7ucx5@anna.jacobs.jacobs-university.de> <20190404.194623.1178346313710501110.mbj@tail-f.com> <01dd01d4eb9c$b9a04160$4001a8c0@gateway.2wire.net> <20190405.142201.707949273328784535.mbj@tail-f.com>
In-Reply-To: <20190405.142201.707949273328784535.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
x-clientproxiedby: AM6P194CA0053.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::30) To HE1PR0701MB2508.eurprd07.prod.outlook.com (2603:10a6:3:72::10)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 600836b4-4a2e-4a3a-8dd0-08d6b9d68219
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2092;
x-ms-traffictypediagnostic: HE1PR0701MB2092:
x-microsoft-antispam-prvs: <HE1PR0701MB2092717E0F5593C7F636BEADF0510@HE1PR0701MB2092.eurprd07.prod.outlook.com>
x-forefront-prvs: 0998671D02
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(39860400002)(376002)(346002)(13464003)(189003)(199004)(386003)(6506007)(26005)(478600001)(71200400001)(71190400001)(5660300002)(229853002)(256004)(93886005)(14444005)(52116002)(6306002)(2501003)(53936002)(54896002)(966005)(8936002)(4326008)(36756003)(68736007)(64126003)(81166006)(486006)(31696002)(86362001)(106356001)(8676002)(102836004)(85202003)(105586002)(81156014)(476003)(6486002)(25786009)(606006)(2616005)(6246003)(99286004)(97736004)(11346002)(2906002)(76176011)(7736002)(31686004)(446003)(6436002)(65806001)(65956001)(66066001)(186003)(65826007)(85182001)(3846002)(6116002)(99936001)(6512007)(110136005)(14454004)(236005)(316002)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2092; H:HE1PR0701MB2508.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4Subje+lgNNuRSnU3U6PkVk1GJA/lQZEHyhkgJ2wm0Xvgq44Vl0KcWf4zTblXu1zUTFQWrDbDuy+8Xw5ryK5qr3XmMYt0J8bqZX6AX/TQgSELgdpFAPY8YCWdGkzBtcP+QJzAUNifILh7PEbNIeRFtB7DVFpogzOzGZq+Sc0udjwxuZ976YVEq2bfGJUk6/BauK8KTfIwVej3OMVJfmdjo+rO9O+BJ8WaBh0ncl8X1TT3FJLAbxriJk2xSe/ru9vvUrvXgiAJBdherxX2tiZf8zVIa4zT0dOQHwlNaOLL3WOMHc5gKH9TGO0gTsf89aZAE5q0CJDo7qgufTjlZNeY36H+35WyN7MJMd7Wynw8dGYO2c6gO6DBOTTiwz6rYinJso5isUkdSVOO3J7otSk61lk9LNYBeCwtJw00UXmBEs=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030100080606040406020605"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 600836b4-4a2e-4a3a-8dd0-08d6b9d68219
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 14:53:48.0179 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2092
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/6io3HJOKT4aiAktZESUV3T4n13Q>
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, 05 Apr 2019 14:54:00 -0000

Hello,

While using actions to configure data nodes instead of edit-config clearly has problems, in some cases it is needed. Ericsson does use it, but we try to be VERY(!) restrictive when it is allowed. IMHO  security best practice could be one case. Also we should not pretend this is the only case where the system itself manipulates configuration:

  • security keys
  • HW insertion/removal (interface type)
  • onboard automation may do it
  • server capabilities that need additional configuration (must be in running as it is reference from other parts of the configuration)

I also hope we will arrive at a solution that works for non-NMDA systems too. AFAIK  we never stated in any RFC that NMDA is a requirement for the solution. (Except for NMDA itself :-)  )

regards Balazs

On 2019. 04. 05. 14:22, Martin Bjorklund wrote:
tom petch <ietfc@btconnect.com> wrote:

----- Original Message -----
From: "Martin Bjorklund" <mbj@tail-f.com>
To: <j.schoenwaelder@jacobs-university.de>
Cc: <netconf@ietf.org>
Sent: Thursday, April 04, 2019 6:46 PM


Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Thu, Apr 04, 2019 at 04:23:23PM +0000, Kent Watsen wrote:


We have always said no, but the reasoning is unclear.  What are

the

specific objections and is there anyway to alleviate them?


If editing of all configuration can be done with a single edit-data
(or edit-config) operation, you simplify the world and you enable
generic implementations.

Once you build silos of data that can only be manipulated with

special

purpose operations, you say goodbye to the idea of generic client
libraries.

And you can no longer create all required config in one transaction;
you have to split it into sending multiple special-purpose actions.
Perhaps also in a certain order, that you have to figure out somehow,
since config might have refererences to other partf of the config
etc.

You can no longer restore a backup with just a copy-config.

Which is exactly what I have seen customers - think military - do.

Security-related information - userid, passwords, second factor , ...-
MUST NOT be backed up like everything else - special procedures -
authentication, encryption -  must be used.

Agreed!  BUT, then it should not be modelled as configuration, imo.

And the current model already handles this case with "hidden" keys.




/martin


This is security - it matters.

Tom Petch


So I don't think the reasoning is unclear at all.

/martin

_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf" rel="nofollow">https://www.ietf.org/mailman/listinfo/netconf



_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf" rel="nofollow">https://www.ietf.org/mailman/listinfo/netconf


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com

v2.23.0 | Report a Bug | By Email