Re: [netconf] updates to client/server drafts

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 17 June 2019 13:01 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 49CE9120048 for <netconf@ietfa.amsl.com>; Mon, 17 Jun 2019 06:01:31 -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, 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, 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 header.b=Zqi3M7m7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fn/yJVq9
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 xo1no9dHNdUK for <netconf@ietfa.amsl.com>; Mon, 17 Jun 2019 06:01:27 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2791200D7 for <netconf@ietf.org>; Mon, 17 Jun 2019 06:01:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45248; q=dns/txt; s=iport; t=1560776487; x=1561986087; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GkIo6HY0CBmvfmU1Y4EX+U3EAcxEE+1FY+RSlv9G1dc=; b=Zqi3M7m7uv1cpBUq1txV7XTOEN6pte7p8Zjg+mr3AQi57h2Y5JQmraly V4cw60uvzRa+LvHEUOdaAAHURyXRv5r4DI3lLS4vzFFvavre+dLqa9pdF yL9heVz+r3h8yFgqz77t4tz8ezLgF620/7Angn4UvNhx/NdYAWxkoqNS/ g=;
IronPort-PHdr: 9a23:F4u7bxHBHyT1e3ymRvSTO51GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AoAAC/jgdd/51dJa1kGgEBAQEBAgEBAQEHAgEBAQGBVAIBAQEBCwGBDi8kLANqVSAECygKhAyDRwOOYYJXlzaCUgNQBAkBAQEMAQEYAQwIAgEBg3pGAheCNSM3Bg4BAwEBBAEBAgEEbRwMhUoBAQEDAQEBEAgJChMBASwLAQsEAgEIEQQBAQEgAQYDAgICJQsUCQgCBAEJBAUIEQIHgwGBHU0DDg8BAgwDnDACgTiIX3GBMYJ5AQEFgTIBAwKDQRiCEAMGgTQBi0AdF4FAP4ERRoJMPoJhAQECgUkCFisJglQygiaLTBIOGhmCHIR0I5YNCQKCEIZIjSWCJ4sNiXyBeYNYh0yBLIV2j0ECBAIEBQIOAQEFgWYigVhwFTuCbIIPDBeDTYUUhT9ygSmMToEwAYEgAQE
X-IronPort-AV: E=Sophos;i="5.63,385,1557187200"; d="scan'208,217";a="579017913"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2019 13:01:06 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x5HD16hL010446 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jun 2019 13:01:06 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 08:01:05 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 09:01:04 -0400
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 17 Jun 2019 08:01:04 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GkIo6HY0CBmvfmU1Y4EX+U3EAcxEE+1FY+RSlv9G1dc=; b=fn/yJVq9YgG8JbD5lrBdjVW3EQAdpt1Xw0EC/4pTjvRF7EDJVqs2yKKdmmtvWn2wzh5ZgpSXQIHeCbULJr2FjAN0fxzAaDd3/9kDergJYWqHtV+0t8gj3y1WAlWLgiwnyQifItOoCOVJ/3/sQo7HktY6Osps6hyY1g9cQDTCxX0=
Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB2837.namprd11.prod.outlook.com (52.135.228.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.14; Mon, 17 Jun 2019 13:01:02 +0000
Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::ed99:b6a8:d6fb:5045]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::ed99:b6a8:d6fb:5045%4]) with mapi id 15.20.1987.014; Mon, 17 Jun 2019 13:01:02 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, tom petch <ietfc@btconnect.com>
CC: Martin Bjorklund <mbj@tail-f.com>, "kent+ietf@watsen.net" <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] updates to client/server drafts
Thread-Index: AQHVHYBcesLv/J1V/0KRNKSxRz3tGaaWvn4AgAA2FICAAi45gIAAUJoAgAACyoCAAD+9AIAADI4AgAFrPVCAAbolgIAC0waQ
Date: Mon, 17 Jun 2019 13:01:02 +0000
Message-ID: <BYAPR11MB26315AAD951B93BFDD361699B5EB0@BYAPR11MB2631.namprd11.prod.outlook.com>
References: <20190613.130024.515576855897220606.mbj@tail-f.com> <20190613111023.ngllkl22zj2vsowp@anna.jacobs.jacobs-university.de> <0100016b5158eba2-6c8348a2-aacc-48c6-adf9-aab39b0ef3a9-000000@email.amazonses.com> <20190613.174326.268927196019178879.mbj@tail-f.com> <BYAPR11MB263110FD55EB83BF76A3E9AFB5EE0@BYAPR11MB2631.namprd11.prod.outlook.com> <CABCOCHQgT=L3-e7GR05uG5UbuxHQ3W8GYYMpSEe7StidX9YR7A@mail.gmail.com>
In-Reply-To: <CABCOCHQgT=L3-e7GR05uG5UbuxHQ3W8GYYMpSEe7StidX9YR7A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.54]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 55feb3f0-54a0-46ef-87d7-08d6f323d9f2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2837;
x-ms-traffictypediagnostic: BYAPR11MB2837:
x-ms-exchange-purlcount: 8
x-microsoft-antispam-prvs: <BYAPR11MB28375E28E5EEF736FED22D19B5EB0@BYAPR11MB2837.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0071BFA85B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(366004)(376002)(39860400002)(189003)(199004)(13464003)(51444003)(14454004)(9686003)(33656002)(26005)(53936002)(6506007)(53546011)(66066001)(76176011)(486006)(256004)(14444005)(102836004)(7696005)(68736007)(478600001)(66476007)(66556008)(64756008)(66446008)(966005)(15650500001)(5660300002)(186003)(3846002)(6116002)(790700001)(2420400007)(25786009)(229853002)(446003)(6306002)(30864003)(66946007)(4326008)(73956011)(76116006)(52536014)(6246003)(74316002)(2906002)(9326002)(7736002)(606006)(6436002)(71190400001)(316002)(8936002)(99286004)(81166006)(71200400001)(81156014)(7110500001)(54896002)(236005)(8676002)(86362001)(55016002)(110136005)(54906003)(476003)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2837; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: BKc2hr1Xt7T4SQWRaDavm75oXEQK/heblgXQgppNC6EItOvohXl5ovCaUMj43RaxyWjhyBcCHdOHEPvsbIxtrtfx3qR1rv0U0L9KSHwKACtXd18pDzx/YwBWuOM9ZPGBRgc1H0WAoY1ur4UenhcF9AkZhD+95LghStbP8WdqCE39Uy9b8tuJusy6Qr3SFMoCCRtnEqzjD5l3XKbdDdtr5+Kf+hJQP6F/h5TwdbI8Ii+tX4hZ7LyZMtLcsNyv3uWJabXZ3cqmOAAQY+AhZgC7nHsglpSeYycqik9Y5DpoybUL7pnuUGwYW3ZWt+8UB0CX0GX8R2DKRXHIhTouP3kopWZBsTEj3C/AXu805G7dBYU0ApLU26XygKDyCOVgEogCjP/rDN0XYvt3JeaxfXKpdqM0RQEeFVOe5u8sHUyoabQ=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB26315AAD951B93BFDD361699B5EB0BYAPR11MB2631namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 55feb3f0-54a0-46ef-87d7-08d6f323d9f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2019 13:01:02.3280 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rwilton@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2837
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/p07QdtqEQblX5Kp8rrbk_263qUI>
Subject: Re: [netconf] updates to client/server drafts
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: Mon, 17 Jun 2019 13:01:31 -0000

Hi Andy,

Generally, we try and avoid actions modifying configuration, but in some cases this might be allowed (e.g. renumbering ACL entries, or disabling some hardware moves active configuration to pre-configuration).

However, the circumstances where an action might be useful for this scenario is potentially a bit different from regular network device configuration.

E.g. some programmatic mechanism to easily add a key to a client device, the scenario described by Tom in:
https://mailarchive.ietf.org/arch/msg/netconf/7zOypLmuSnMUIYfsc_wTl2nS-84

I don’t know the exact details of what is required here, but having an action (or RPC), dependent on a feature, might be reasonable for this scenario.  I would see this purely as an alternative mechanism to achieving the same end goal as regular configuration, potentially to allow different NACM rules on the action/RPC.

Thanks,
Rob


From: Andy Bierman <andy@yumaworks.com>
Sent: 15 June 2019 16:46
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>; kent+ietf@watsen.net; netconf@ietf.org
Subject: Re: [netconf] updates to client/server drafts



On Fri, Jun 14, 2019 at 10:30 AM Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>> wrote:
Hi Martin, Kent,

> -----Original Message-----
> From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> On Behalf Of Martin Bjorklund
> Sent: 13 June 2019 16:43
> To: kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>
> Cc: netconf@ietf.org<mailto:netconf@ietf.org>
> Subject: Re: [netconf] updates to client/server drafts
>
> Kent Watsen <kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>> wrote:
> >
> > >>> I am strictly against hiding actions by encoding 'verbs' in an
> > >>> ad-hoc data format. I rather not support creation of keys on the
> device.
> > >>
> > >> Remember we had this cases:
> > >>
> > >> 1.  upload of keys
> > >> 2a. generation of keys on the box that will go into hardware
> protected
> > >>    storage (and never be accessible) 2b. generation of keys on the
> > >> box that will be stored on disk
> > >>    (and never be accessible over the mgmt interface) 3.  generation
> > >> of keys on the box that become (protected) configuration
> >
> > This list is missing cases #1 and #3 described here:
> > https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7u
> > Icc
> >
> <https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc
> >.
>
> #1 (pre-existing key in hw) is orthogonal to the pain points we have here;
> it should be possible to handle this case.
>
> #3 (upload of hidden key) should also be straight forward with an action.
>
>
> > Also, we currently make no distinction between (2a) and (2b) - hidden
> > is hidden, however it's implemented.
>
> I know, but the discussion seems to imply that this would be useful and it
> seems trivial to support.
>
>
> > >> I think the previous version of the draft (with YANG actions)
> > >> handles
> > >> 1 and 2 (a and b with trivial updates).
> > >>
> > >> It is only (3) that we don't have a solution for that everybody
> > >> accepts.
> > >>
> > >> So perhaps we should solve 1 and 2a and 2b, and publish that, and
> > >> leave 3 for the future?
> > >
> > > This may be a way to move forward. In 2a and 2b, will there be a way
> > > to remove a generated key via the mgmt interface or do I have to
> > > take a bigger hammer to accomplish this?
> >
> > I object to reverting to the approach that doesn't have the key's
> > 3-tuple (algorithm, public key, private key) marked as mandatory true,
> > our doing that before was unhelpful.
>
> I need to go back and re-read (again, I just read all threads on this
> issue) some mails to understand what this means.
>
>
> > I was hoping that the "verbs"
> > approach could leap over the impasse but, if Juergen is strictly
> > against it, then we should go back to the approach described here:
> > https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJ
> > usY
> > <https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQM
> > JusY>, for which a draft was never published.
> >
> > In the previous link, search for "Now let's discuss what this action
> > does" and note the two options: (1) is more user-friendly, but one
> > that Martin appears to be strictly against
>
> Yes, and Andy and Rob (at least).  And I do not agree that it is user
> friendly at all!

I don't think that I'm necessarily against having an action (or RPC) that generates a pair of keys and writes them to configuration as a special type of configuration update.  But I would very much regard this as a special case that is designed as a combined action/RPC solely to make life easier for clients rather than the defacto approach.  I.e., I would like there to be an equivalent mechanism that works, is just as secure and complete, using regular NETCONF <edit-config> config operations and normal semantics.  Then the question becomes: If we can do this using regular NETCONF semantics, do we still need a separate "easy to use" action/RPC as well?



IMO it is fair to ask how many servers support actions that change configuration today?
If several vendors say "this is great! we use it all the time! no problems at all!" then
it is probably appropriate for standardization. Otherwise, not so much.
(I don't think any vendors use this design pattern now)


[RW]



>
> > and so perhaps (2) is all
> > we can agree on, and yes, there would need to be a third (not
> > mentioned) action to delete the key from <operational> (presumably
> > after having deleted the same from <running>).  Yes, it is less
> > friendly, if you want more friendly, then let's do (1).  I'll update
> > the draft shortly based on the less-friendly approach (2).
>
> I don't think (2) is the right solution either.  I think the previous
> version of the draft was very close to a workable solution.
>
> > That said, I'm also okay with giving up (for now) trying to enable a
> > client request the server to generate a key (hidden or not) or request
> > the server to install a hidden key [note: these are #2 and #3 in my
> > first link above].
>
> I don't it is necessary to give up this.
>
> IMO the only problematic use case is "let the device generate a key that
> then becomes part of the config".  If we avoid that I think we can handle
> the other cases.

I think that Juergen's idea of "store the name of the key in the <running> configuration, but not necessarily the value" is along the right lines.
 - If the client is willing to write the key into the configuration, perhaps obfuscated, or encrypted, then that is fine.
 - If the client wants the server to allocate the keys that also works.

Taking Kent's tree diagram from the 3rd of May, perhaps this could be modified from:

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw algorithm?                             <--- optional?
              +--rw public-key?                            <--- optional?
              +--rw private-key?           union           <--- optional?   (note union)
              +---x generate-hidden-key
              +---x install-hidden-key
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]

to something like this:

     +--rw keystore
        +--rw asymmetric-keys
           +--rw asymmetric-key* [name]
              +--rw name
              +--rw type!                                  <-- New mandatory field
              +--rw algorithm?                             <--- optional
              +--rw public-key?                            <--- optional
              +--rw private-key?           union           <--- optional
              +---x regenerate-hidden-key
              +---x install-hidden-key
              +---x generate-certificate-signing-request
              +--rw certificates
                 +--rw certificate* [name]

Where the new "type" enum field could have 4 options such as:
 - plain-text <= configured algo, public/private keys in raw format (not secure, transferable)
 - obscured   <= as above, but obscured with a known reversible mechanism (not secure, transferable)
 - encrypted  <= as above, but encrypted using server's public key (secure, not transferable)
 - server-allocated <= only name and optionally algorithm in running config, the server allocates the key when applying the configuration, public key is available in operational, private key is never reported.  Key pair is persisted outside of YANG configuration.

YANG "must" statements could be added to "algorithm", "public-key" and "private-key", to enforce that these are always provided if type is (plain-text, obscured, encrypted).

The "regenerate-hidden-key" action would allow a server-allocated hidden key to be regenerated if required.  If user configuration caused the key to be created in the first place, then the key would also be deleted if the key list entry is deleted from configuration.

A server could also automatically create its own key, without any user intervention.  The server chooses the key name, and the key would be of type "server-allocated" but it would only exist in operational (origin=system).  If the key needs to be referenced in configuration then the client would need to configure (asymmetric-key, name=<server-assigned-key-name>, type=server-allocated) into the configuration.  Subsequently removing the configuration wouldn't delete the key (because it is system created, and always exists), but regenerate-hidden-key should work to force the key to be regenerated if required.  The server persists the key outside of YANG configuration.

The "install-hidden-key" action would allow a client to replace any server-allocated hidden key.

Finally, if we are concerned about ease of use, then I would OK with a RPC being defined that performs an edit-config request to just add a named asymmetric-key of type server-allocated.  The RPC could also return the public key that has been generated by the server.  Note that this RPC isn't required, everything that can be done with the RPC can still be achieved through editing the configuration using edit-config, and reading the public key back with get-data, its only purpose to simplify a use case for clients, and perhaps to allow it to have different NACM permissions.

Would a scheme like this work?  Or am I [still] missing something?


I also like Juergen's approach.



Thanks,
Rob


Andy



>
>
> > I would support this less complete solution because it still supports
> > basic configuration (#0) and manufacturer-generated keys for, e.g.,
> > IDevID certificates (#1), and thus a passable go-to-market solution.
> > If folks don't like the update per the previous paragraph, then this
> > looks like a good fallback.
>
>
> /martin
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org<mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf