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

Michal Vaško <> Wed, 28 April 2021 07:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17C963A1DCE for <>; Wed, 28 Apr 2021 00:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7O-rAAUqnVLu for <>; Wed, 28 Apr 2021 00:23:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABF9A3A1DCB for <>; Wed, 28 Apr 2021 00:23:11 -0700 (PDT)
Received: by (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;; 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: Michal Vaško <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Date: Wed, 28 Apr 2021 09:23:09 +0200
Cc: Kent Watsen <>, "" <>
To: Juergen Schoenwaelder <>
MIME-Version: 1.0
Message-ID: <38a8-60890d80-47-ca98650@116585071>
User-Agent: SOGoMail 5.1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [netconf] Latest ietf-netconf-server draft and related modules
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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: <>
> > 
> 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         <>