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

Michal Vaško <mvasko@cesnet.cz> Thu, 29 April 2021 05:41 UTC

Return-Path: <mvasko@cesnet.cz>
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 7D29F3A30C6 for <netconf@ietfa.amsl.com>; Wed, 28 Apr 2021 22:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=cesnet.cz
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 Ss85L6_DVOTZ for <netconf@ietfa.amsl.com>; Wed, 28 Apr 2021 22:41:03 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9065D3A30C5 for <netconf@ietf.org>; Wed, 28 Apr 2021 22:41:02 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 1065C6007D; Thu, 29 Apr 2021 07:40:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619674858; bh=MgAjAb40cN33JsXOBY8QFiliH/WwdnyR4itfR6BDXHI=; h=From:In-Reply-To:Date:Cc:To:Subject; b=PD9EpTW8n0in8fqDT7Ufc5monJhImiJYj9JMGq/XUf471Y5Gqm26cbmSHInIUn5dM kXJ1vk+R/Ht3+/AQXJ1cbUUCpu2mVK+bBN8CBt6ARjMMpNYA83/TMUi21pi2DO53i7 fgM/oVMqUscjzpzGNtvJ3pyT5p3yfZU1/1wmTs8I=
From: =?utf-8?q?Michal_Va=C5=A1ko?= <mvasko@cesnet.cz>
In-Reply-To: <010001791a9063c8-c7d5b566-f0d1-4606-a978-2e2d183284d7-000000@email.amazonses.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 84.42.188.124
Date: Thu, 29 Apr 2021 07:40:58 +0200
Cc: =?utf-8?q?netconf=40ietf.org?= <netconf@ietf.org>
To: "Kent Watsen" <kent+ietf@watsen.net>
MIME-Version: 1.0
Message-ID: <972-608a4700-29-1b90d060@24617716>
User-Agent: SOGoMail 5.1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-Qr2BOvEl5jCSpFT9k7FwGFv4-o>
Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_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 05:41:09 -0000

Hi Kent,

> > Still, I think we are pretty close now, from my perspective. As was discussed, the "keyboard-interactive" method is a completely generic one where the user is presented with a set of challenges and must correctly respond to them to pass the authentication. That should already work and the issue I was trying to solve is a security one, when the expected response is some sensitive information. Adding that, I think the configuration would be able to (safely) express all configurations that do not require any additional information (such as, I don't know, retrieving the expected response from some remote server). Incidentally, the expected response of the user password would also be supported.
> 
> The problem with the current keyboard-interactive model is that each “response” is effectively a password, even if it’s not a password, in that it is the magic answer that the client needs to provide.  
> 
> Thus, all the responses SHOULD be, e.g., hashed, so that the value that needs to be provided isn’t in the clear.  In this sense, we could use the iana:crypt-hash type for the “response” node, pushing it to the administrator to configure the hashed values.

That is true and would make sense.

> That said, if we’re leaning towards static/canned “keyboard-interactive” config being sold for, e.g., unit-testing, it would be easier on the administrator to leave the values in the clear.

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.

> >>> This is probably just a YANG modeling issue. I was already thinking about 1) and it seems to me it would make for a nice configuration data, but the YANG itself would be cluttered. Nevertheless, there may be a clean solution I am missing so it is up to you. We have simply assigned a priority to each authentication method, but I am not saying that is ideal.
> >> 
> >> #1 seems better at first but, assuming the list is called “authentication-method”, the immediate issue is what the “key” should be.  We’d have to introduce a somewhat artificial “name” node, which makes the approach less appealing.
> >> 
> >> #2 seems easy enough:
> >> 
> >>   leaf-list preferred-authentications {
> >>     type enumeration {
> >>       enum publickey { ... }
> >>       enum password { ... }
> >>       enum hostbased { ... }
> >>       ...
> >>     }
> >> 
> >> But new “enums” cannot be augmented into an “enumeration” (in case that is ever desired).  We could use “type string”, but that's too open.  Another option would be to define a hierarchy of identities and then have a leaf-list of identityrefs.  This could work, but...
> >> 
> >> Now I’m thinking to leave the order unspecified, since it’s a minor optimization (saving a round-trip), as the “none” option can be used to get a “productive methods” list from the server.
> >> 
> >> You said that you’d did this optimization before, but did it really matter, to save one roundtrip, especially in the context of using the keyboard-interactive method?
> >> 
> >> How about this for the the “client-identity” node’s description?
> >> 
> >>      "The credentials are unordered.  Clients may initially send
> >>        any configured method or, per RFC 4252, Section 5.2, send
> >>        the 'none' method to prompt the server to provide a list
> >>        of productive methods."
> > 
> > Like I said, the best example of a problem we were solving with these priorities was that when your SSH client has both "publickey" and "password" authentications supported and working and you connect to an SSH server that supports the "publickey" authentication, it is probably the method you prefer. I may be missing something but how do you solve this problem without some way of expressing these priorities explicitly? I do not see how getting the supported methods from the server will help you, it is strictly up to the client which of the methods it will select next (first).
> 
> I understand you’re trying to enable the client to know exactly the right auth mechanism to use first.  My last response was, effectively, “let’s NOT solve that problem, because it’s a minor optimization, saving just one round-trip."
> 
> 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.

Regards,
Michal