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

Kent Watsen <kent@watsen.net> Mon, 19 April 2021 17:48 UTC

Return-Path: <01000178eb3f0c88-bfd76315-200a-4bcb-982f-8700be82ef77-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 2738C3A3C61 for <netconf@ietfa.amsl.com>; Mon, 19 Apr 2021 10:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Level:
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 DKf0-eGMvNng for <netconf@ietfa.amsl.com>; Mon, 19 Apr 2021 10:48:02 -0700 (PDT)
Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828743A3C5F for <netconf@ietf.org>; Mon, 19 Apr 2021 10:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618854481; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=MtKBs+GvnTdTGV2lWkQW6IwaGUHCqsRteXX8orh8mhc=; b=JHdeWVw30aVpPMKIiidJ2iP7dBl66uCp1G+CwZt0YPzHxaLbIIP3pQbVXvoMneln Mx+h61jEo5PaKU9ukq0cll1UFdIZIUqe/Nh1gnel7kcsTPAokUHwNeegs1BfpckJvui Pac3uZJ3CrYeK+7tecQScIty4bsCgLTp0aBbW6Cw=
From: Kent Watsen <kent@watsen.net>
Message-ID: <01000178eb3f0c88-bfd76315-200a-4bcb-982f-8700be82ef77-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BE7172E0-9998-4617-AB58-ECF3D7C24285"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 19 Apr 2021 17:48:01 +0000
In-Reply-To: <66c7-606b1980-11-21ab2140@196626001>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: =?utf-8?Q?Michal_Va=C5=A1ko?= <mvasko@cesnet.cz>
References: <66c7-606b1980-11-21ab2140@196626001>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.04.19-54.240.48.92
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Xczgd8H9XcQGVY3Qs6w3qMAEMKo>
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: Mon, 19 Apr 2021 17:48:07 -0000

Hi Michal,

Please find responses below.

K.


>>>>> - 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?
>>> 
>>> That is a good question. It seems no other methods are standardized but that does not mean they are not used.
>> 
>> What change are you hoping to see?  Is there anyway that such changes could be augmented in, or must they be in the base module?
> 
> Okay, so properly looking at all this, the 2 missing authentication methods (that are supported by libssh or sshd, or example) are actually standardized so I suppose you can add them directly into the YANG module. There are "keyboard-interactive" [1] (not "interactive") and "gssapi-with-mic" [2].
> 
> [1] https://tools.ietf.org/html/rfc4256 <https://tools.ietf.org/html/rfc4256>
> [2] https://tools.ietf.org/html/rfc4462 <https://tools.ietf.org/html/rfc4462>

Thanks for tracking those RFCs down.

From RFC 4256, the "keyboard-interactive” auth method was added here: https://github.com/netconf-wg/ssh-client-server/commit/6cc6a9ecd0be7db01c6a1ba39ed7b32ac6310163.

From RFC 4462, the "gssapi-with-mic” and “gssapi-keyex” auth methods were added here: https://github.com/netconf-wg/ssh-client-server/commit/ea518a6d7accc1cda656a5d1bc1300abf1c62f5a

It would be great if you could verify these additions.  I’m not myself configuring any SSH clients or servers, and thus the configuration-formulations are purely academic based on my reading of the RFCs.

Additionally, in ietf-ssh-server, the whole "client-authentication” container, especially its "supported-authentication-methods” and “users” descendent nodes, seem less than ideal.  Have you been using these trees, do them seem to be formulated correctly?


>>>>> 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...
>>> 
>>> Right, that would solve the problem, too. So you can keep it the way it is, up to you which solution you prefer. Not sure why I did not think of augments first but identityrefs. But identityrefs are much more general so the implementation should probably depend on whether these authentication methods are to be used only for this single purpose or not.
>> 
>> Either way is fine with me.  As the module is in WGLC currently, it would be good if others could express an option...

Anyone?



>>>>> - 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?
>>> 
>>> Yes, I think "or" fits much better. I just was not sure whether there is not a specific reason why "and" was chosen.
>> 
>> OLD:        "(tls-listen or tls-call-home) and (sshcmn:ssh-x509-certs)”;
>> NEW:        "tls-listen or tls-call-home or sshcmn:ssh-x509-certs";
> 
> Well, this is no good either because now ANY of those features are enabled, the certificates will be supported for BOTH TLS and SSH. What should be possible to support is X509 certificates for SSH, TLS, or both. That would require some more remodeling of "netconf-server-grouping", not just an "if-feature" update.

But I wasn’t trying to fix your original issue.  As mentioned, there is a YANG-next issue and the best that consuming modules can do is to 1) enable all the features defined in these modules and 2) augment-in “use”-specific feature statements where the groupings are used.

My OLD/NEW update is trying to correct a logic error.  I believe the new formulation is correct.  It could be expanded to;

	(tls-listen or tls-call-home)
	or 
	( (ssh-listen or ssh-call-home) and sshcmn:ssh-x509-certs)

But I don’t think "(ssh-listen or ssh-call-home)” is needed, as certainly one would be true when "sshcmn:ssh-x509-certs” is enabled, right?



K.