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

Kent Watsen <kent+ietf@watsen.net> Thu, 29 April 2021 13:48 UTC

Return-Path: <010001791de3029b-730530a6-f4fb-4d57-9d39-a1551ab76260-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 B341C3A3F51 for <netconf@ietfa.amsl.com>; Thu, 29 Apr 2021 06:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, 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 yJtr7d1cCLzL for <netconf@ietfa.amsl.com>; Thu, 29 Apr 2021 06:48:09 -0700 (PDT)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538763A3F52 for <netconf@ietf.org>; Thu, 29 Apr 2021 06:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619704088; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=TXBZRRgmhCy+zDeEcNoGD6dII07SfmZO7Vnmo3Ek2OA=; b=Cg40iNlzY2jV8ZMbiu0+uaQuLvCuRqCvmvN7n/JwktWfqoDteeQco5d3uQWqZAvV uFaWwVwGwOrpEF7pX0RggkJtsuvAZZ3ZDIupiR3oghECC2aqURLezAuXqt5cU2o/+Ee ptZPQAgQa/aQawyDDFQdTI60+3Fug4XbdhL8889g=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <972-608a4700-29-1b90d060@24617716>
Date: Thu, 29 Apr 2021 13:48:07 +0000
Cc: "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <010001791de3029b-730530a6-f4fb-4d57-9d39-a1551ab76260-000000@email.amazonses.com>
References: <972-608a4700-29-1b90d060@24617716>
To: =?utf-8?Q?Michal_Va=C5=A1ko?= <mvasko@cesnet.cz>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.04.29-54.240.48.110
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/OTRWbT6_hAeiAESHOTmk3-gH1iA>
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: Thu, 29 Apr 2021 13:48:11 -0000

Hi Michal,

> I do not really see the point of having the configuration there just for testing purposes. With all the feedback provided, it seems to me now that all the configuration of "keyboard-interactive" should be scratched and leave it just as a presence container to allow augments. With a description mentioning them and the possibility of using PAM or similar authentication methods.

Could provide how you used “keyboard-interactive” before?  Was config such as in the current model used, or was it actually interacting with an PAM-like mechanism?

 

>> My question before was (and still is), since you did this optimization before, did it really matter (to save that roundtrip), especially in the context of using the (very slow) keyboard-interactive method?
> 
> But how is it saving just one round-trip? If you are offered "password" authentication but want to use "publickey" instead, let's say, you will likely leave the input empty just so that it fails and you get to the next method. But that causes a failed authentication attempt, if nothing else, which I do not think is that harmless.

I’m unsure if you understand the SSH protocol, so here goes:  the client starts off with an auth method.  It can optimistically pick one (e.g., if it only has one to choose, then it has nothing to lose by picking it) or pick “none”.   In either case, if the server is unhappy with the method selected by the client (and it always will be when “none” is selected), the server responds with a list of “productive” methods the client should try next.  

The question is, how important is the ability to configure a “first” method (assuming more than one has been configured)?

My guess is that it’s not important as follows:

1) I assume the client is not resource-constrained (as, if it were, then it would likely be using TLS instead of SSH).  Thus, in the worst case, where the client performs some expensive key operation, it’s not a big deal because it has the resources to do it quickly.

2) Assuming the client sends an “expensive method” first, and the server isn’t configured to support that method first, it will not waste any CPU cycles doing an expensive key operation; it will simple return a failure with a list of “productive” methods.

Thus the net-impact is some wasted CPU-cycles on the client and the latency incurred by one unnecessary roundtrip.  Assuming the client is not resource-constrained, the only significant variable is the network and, in a very high-latency network, it could be important.  Thoughts?


K.