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

[Juergen Schoenwaelder <[e-mail]>]

Let me quote from RFC 4256:

   [...] The major goal of this method is to
   allow the SSH client to support a whole class of authentication
   mechanism(s) without knowing the specifics of the actual
   authentication mechanism(s).

   [...] The major goal of this
   method is to allow the SSH client to have little or no knowledge of
   the specifics of the underlying authentication mechanism(s) used by
   the SSH server.  This will allow the server to arbitrarily select or
   change the underlying authentication mechanism(s) without having to
   update client code.

   The name for this authentication method is "keyboard-interactive".

If we model something as keyboard-interactive, it can't be a list of
static strings to justify that name.

My reading is that the SSH protocol talks about users. Whether these
users map to system level accounts (as they would do with a regular
sshd) or to some notion of 'virtual' users (on a system that shields
the system behind a NETCONF server) is I believe an implementation
choice.

/js

On Wed, Apr 28, 2021 at 09:23:09AM +0200, Michal Vaško wrote:
> 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/>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>