IETF Logo Mail Archive

Re: [netconf] ietf crypto types - permanently hidden

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 05 April 2019 10:14 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 E5D821200F6 for <netconf@ietfa.amsl.com>; Fri, 5 Apr 2019 03:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, HTML_MESSAGE=0.001, 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 V9AvY7a4zOfl for <netconf@ietfa.amsl.com>; Fri, 5 Apr 2019 03:14:33 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFDF120086 for <netconf@ietf.org>; Fri, 5 Apr 2019 03:14:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13362; q=dns/txt; s=iport; t=1554459272; x=1555668872; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2FjqCseOiG12gKWwgo7m5qIGDNAVKrT+bxEuh/FX3ZY=; b=iWTWPGKEPflA1nY8DtZP59o48VmNJm+PjRLxy1JHtdcPpTVegcZ3NUt9 2Pla9pG9uLizYAESZcysHYJoxpnIZAlZHwKdsD+EeTRcfiiX6nlMhNqBQ IRor70Emx3ykcNtzhRjfsLQIGsEg+B1lU2w2ji/K0W7rh9Cpoh5SJ3jND 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAAAtKadc/4gNJK1lGgEBAQEBAgEBAQEHAgEBAQGBVAIBAQEBCwGBDoECaIEDJwqEBJVHkk6Hcw4BAYRsAheFOyI3Bg0BAQMBAQkBAwJtKIVKAQEBBCMKTBACAQgRBAEBKwICAjAdCAIEDgUIE4MIgRFkrx2BL4o0gTABiXCBRBeBQD+BEYMSPoQugyCCVwONDoQqlD0JApN3IpRVg1abdAIRFYEwNSKBVnAVgyeQTEExj0uBIAEB
X-IronPort-AV: E=Sophos;i="5.60,312,1549929600"; d="scan'208,217";a="257197405"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Apr 2019 10:14:31 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x35AEVha024726 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Apr 2019 10:14:31 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Apr 2019 05:14:30 -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, 5 Apr 2019 05:14:30 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Martin Bjorklund <mbj@tail-f.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAB55r2AAFc4f4AA2LGYAAAA+NoAAOhJxAAAPAjogAAJwD2w//+/vgD//zkDAA==
Date: Fri, 05 Apr 2019 10:14:30 +0000
Message-ID: <3ee1585d967540299a96169814e90a90@XCH-RCD-007.cisco.com>
References: <VI1PR07MB47351FF76BBF6C56AC6E64B5835E0@VI1PR07MB4735.eurprd07.prod.outlook.com> <01000169cb20ec39-94187bed-9312-4e19-a91f-466db763ee7e-000000@email.amazonses.com> <20190329205316.tcjzicuythyd4gvm@anna.jacobs.jacobs-university.de> <20190403.134424.1377386644961079970.mbj@tail-f.com> <01000169e929781e-b0dcb6b3-af41-4f9c-ba52-ac4afb7164d4-000000@email.amazonses.com> <a668ce8a370049769a82eb1250f139e3@XCH-RCD-007.cisco.com> <01000169e95687c5-a1809710-e13d-4bc3-a5d3-5387af4112b7-000000@email.amazonses.com>
In-Reply-To: <01000169e95687c5-a1809710-e13d-4bc3-a5d3-5387af4112b7-000000@email.amazonses.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.177]
Content-Type: multipart/alternative; boundary="_000_3ee1585d967540299a96169814e90a90XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/1ofOTJ_v-ix8xWB6kFtdlhoit-g>
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 10:14:35 -0000

Hi Kent,

But clients are also allowed to explicitly configure public and private keys in the configuration?  (I.e. the “upload of keys” previous described).

If a private key is uploaded in the configuration, would that private key still be readable by the client in <running>, <intended>?  Or would that also be blocked via NACM by default?

I’m trying to understand once the keys are generated, how these two cases differ?

1) upload of keys

2) generation of keys on the box that become (protected) configuration

If a client does not want to explicitly upload keys then are they forced to explicitly do (2) to generate keys?  Or could the system automatically generate persistent keys?

Thanks,
Rob


From: Kent Watsen <kent+ietf@watsen.net>
Sent: 04 April 2019 18:13
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>; netconf@ietf.org
Subject: Re: [netconf] ietf crypto types - permanently hidden



[RW]
I think that is bad practice for a server to inject configuration into <running>.  It makes it ambiguous as to which entity really owns the configuration.   I think that what is in <running> should be owned by the client, not the server.  I’m not saying that nobody does this, but I don’t believe that it is the cleanest solution.


We're not talking about the server doing something on its own accord here; this would be a direct result of a client request.  Abstractly, such can be considered configuration as legitimate as configuration provided by any other means.

Kent // contributor

v2.23.0 | Report a Bug | By Email