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

[Juergen Schoenwaelder <[e-mail]>]

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".
 
> > 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.

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.

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.

> 
> 
> > 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/>