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

Michal Vaško <mvasko@cesnet.cz> Wed, 28 April 2021 07:23 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 17C963A1DCE for <netconf@ietfa.amsl.com>; Wed, 28 Apr 2021 00:23:18 -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 7O-rAAUqnVLu for <netconf@ietfa.amsl.com>; Wed, 28 Apr 2021 00:23:12 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.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 ABF9A3A1DCB for <netconf@ietf.org>; Wed, 28 Apr 2021 00:23:11 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 5B1D66007E; Wed, 28 Apr 2021 09:23:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619594589; bh=DCKq9Wx1gN9zM3GJeb9AC5HrGD3B/6/IGXqSePCB/nU=; h=From:In-Reply-To:Date:Cc:To:Subject; b=wTp8vDoE7Rbe59yq32pocTEAPD60nkSejbYGsud3QGZOTfHAcFSc/xwP3EQ6Mxafz VC/6J9Vm7Zl5UIagpS1MGF/faqEYWpLRaBXttz0Ia/v/8kv2FzQAepMDDuig+IvbfR 5mWLmkc7N3Z2ON1RY7pRf7p9tJxtjnvTKr6hKPFs=
From: =?utf-8?q?Michal_Va=C5=A1ko?= <mvasko@cesnet.cz>
In-Reply-To: <20210428071116.33uc3m2vzo5gq6lf@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"
X-Forward: 84.42.188.124
Date: Wed, 28 Apr 2021 09:23:09 +0200
Cc: "Kent Watsen" <kent+ietf@watsen.net>, =?utf-8?q?netconf=40ietf.org?= <netconf@ietf.org>
To: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
MIME-Version: 1.0
Message-ID: <38a8-60890d80-47-ca98650@116585071>
User-Agent: SOGoMail 5.1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/VVhZc00FIwNRl91iP-IAwfzC_g4>
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: Wed, 28 Apr 2021 07:23:18 -0000

Hi Juergen,
I tried to explain below that your understanding of the configuration meaning is wrong, let Kent correct me if it is me who got it wrong.

> On Tue, Apr 27, 2021 at 10:45:21PM +0000, Kent Watsen wrote:
> > 
> > I’m a fan for just tying up the loose ends Michal is raising, but I thought you were advocating something else?
> >
> 
> I am not advocating anything. I just tried to clarify that
> keyboard-interactive is a complex authentication mechanism to model
> since you have to model some of the functionality of PAM for it.  If
> you enable keyboard-interactive in your sshd config, you are
> essentially saying "go and read the PAM configuration to figure out
> what will happen".

That is specific to sshd and is supported in the modules if you disable "client-auth-config-supported". But if you enable it, you want to configure the authentication yourself, in the module.

> > > a) Is the issue that there is no support for keyboard-interactive in
> > >   the SSH model?
> > 
> > There is now per this commit: https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0 <https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0>
> > 
> 
> To me this makes little sense, you are not done by statically
> configuring challenges and responses, this is from my view really
> missing the point of keyboard interactive. I am sure you can write
> a PAM module that does that but the value of keyboard is not this
> kind of trivial configuration.

Reading the RFC that defines this method, I think it models it exactly the way it is defined. Please ignore PAM, it is not used if this configuration is in-effect.

> My point is that if we model keyboard-interactive, we have to get it
> right, which is complex. Hence my suggestion is to not model it at this
> point in time.

It seems fairly straightforward, from its definition.

> I also stumbled over
> 
> 	"A list of locally configured users (i.e., SSH clients).";
> 
> For me, an SSH client and a locally configured user are very different
> things. For me, the SSH client is the piece of code running on the
> client side, the user is an account on the remote system.

Again, the point of having "client-auth-config-supported" enabled is that you do not read the authentication information from the system and ignore any 'accounts on the remote system'. Instead, you configure the allowed users yourself.

> > 
> > 
> > > b) Is the issue that there is no support for non-local user databases
> > >   for SSH and HTTP authentication?
> > 
> > If we think that is important, yes.  The current “solution” for non-local user databases is 1) don’t enable "client-auth-config-supported” and 2) augment-in what is needed for the application…and maybe 3) only use TLS, where the truststore/keystore + cert-to-name obviate the need for a user database.
> > 
> 
> Well, you can configure SSH user authentication mechanism to reach out
> to RADIUS or Kerberos or Diameter or ... RFC 7317 does support the
> RADIUS backend option. Having to augment in new trees to support lets
> say RADIUS is somewhat expensive. (I _assume_ you can call out to
> RADIUS from the SSH password authentication method, i.e., this may not
> require to have keyboard-interactive.) But perhaps also this can be
> dealt with once there is more implementation experience.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>