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

[Michal Vaško <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>