Re: [netconf] Latest ietf-netconf-server draft and related modules

Kent Watsen <kent@watsen.net> Fri, 05 March 2021 23:19 UTC

Return-Path: <0100017804af516b-fff3cc4f-3806-4108-a448-db4249a437a4-000000@amazonses.watsen.net>
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 28CF13A1757 for <netconf@ietfa.amsl.com>; Fri, 5 Mar 2021 15:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.907
X-Spam-Level:
X-Spam-Status: No, score=-7.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 rxnBP9JnkU3w for <netconf@ietfa.amsl.com>; Fri, 5 Mar 2021 15:19:14 -0800 (PST)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086C83A1645 for <netconf@ietf.org>; Fri, 5 Mar 2021 15:18:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1614986301; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=IumUn/XPH5PR4GTaqHtCx+EGlpIWsShITiplMtLUjlY=; b=DsZeFUF/IZh7Jsxhx2zytkNW6kAEmwNQmnw/jtLUiToJDGzp3Ae2DxHp2shlFTzH e5yGDbP6oNFyZ4lFz6SZibQTLlrY7xU05VD2x3oyN907ZYk5Zm3DypflMl5373RmKqK VZPzeHTpZeHkgGU3ozme201cMQE8ZouSfkYeo5dg=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100017804af516b-fff3cc4f-3806-4108-a448-db4249a437a4-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CB2475E3-F7A7-447A-B419-CA912C2B9D9D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 05 Mar 2021 23:18:21 +0000
In-Reply-To: <67bf-6041e780-35-f195530@37659174>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: Michal Vaško <mvasko@cesnet.cz>
References: <67bf-6041e780-35-f195530@37659174>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2021.03.05-54.240.48.94
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4gXyyI5SB0jWVXz1qpOAlt1e-qM>
Subject: Re: [netconf] Latest ietf-netconf-server draft and related modules
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 Mar 2021 23:19:22 -0000

Hi Michal,


> I had a chance to look at these modules again and have 2 questions regarding some recent changes.
> 
> - ietf-ssh-server, ssh-server-grouping/client-authentication/supported-authentication-methods
> 
> Since the "other" leaf-list was removed there is no way to support some other methods than those specified. I am not sure whether this was the intention and if so, what is the reason for it? If nothing else, we support "interactive" authentication method but there are some others that I see no reason why they could not be used.

It took me a bit to determine that this change happened in ssh-client-server-18.

The motivation behind the change was to align the values with those defined in RFCs 4252 and 4250.

You mention an “interactive” and “some other” methods - where are they defined?


> For a robust and extendible solution, why not use an identityref leaf-list with all the methods as identities? One could then simply add new ones with specific "if-feature" statements.

An identityref seems reasonable, could you propose a snippet of YANG for it?

That said, it seems equally possible for a future module to augment-in a new leaf under the "supported-authentication-methods” container...


> - ietf-netconf-server, grouping netconf-server-grouping/client-identity-mappings
> 
> The "if-feature" on this container is strange. The practical problem is that if one wants to support certificates only for TLS, both one of the TLS features and "ssh-x509-certs" must be enabled. This then results in the container being defined for both SSH and TLS so there is no way to support it only for TLS or SSH.

Yes, granular features would be nice.  This issue is tracked here: https://github.com/netmod-wg/yang-next/issues/82 <https://github.com/netmod-wg/yang-next/issues/82>.  A possible fix would be to enable features on a per-XPath basis, perhaps using the “node-tags” draft going on in NETMOD.   Do you have a proposal?

BTW, shouldn’t the “if-feature” statement have an “or” (not an “and”) between the two major expressions?


K.