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

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Apr 29, 2021 at 04:56:35PM +0200, Michal Vaško wrote:
> > The question is, how important is the ability to configure a “first” method (assuming more than one has been configured)?
> > 
> > My guess is that it’s not important as follows:
> > 
> > 1) I assume the client is not resource-constrained (as, if it were, then it would likely be using TLS instead of SSH).  Thus, in the worst case, where the client performs some expensive key operation, it’s not a big deal because it has the resources to do it quickly.
> > 
> > 2) Assuming the client sends an “expensive method” first, and the server isn’t configured to support that method first, it will not waste any CPU cycles doing an expensive key operation; it will simple return a failure with a list of “productive” methods.
> > 
> > Thus the net-impact is some wasted CPU-cycles on the client and the latency incurred by one unnecessary roundtrip.  Assuming the client is not resource-constrained, the only significant variable is the network and, in a very high-latency network, it could be important.  Thoughts?
> 
> I am not sure what the problem is but it seems we are still not understanding each other. My specific example is as follows. The client uses "none" method first to get the list of supported methods, always. Then, based on the returned methods, it gets the set of supported methods on both the server and the client. The problem is, what should be the order of trying to authenticate using these methods? Like I said before, if a more complex method is selected instead of a simpler one, it may result in additional failed authentication attempt (and client disconnect if none are allowed), minor user annoyance, and even wasted server CPU time, yes. I consider the first problem serious enough that would like the module to support configuration that could prevent it.
>

RFC 4252 says:

   The server drives the authentication by telling the client which
   authentication methods can be used to continue the exchange at any
   given time.  The client has the freedom to try the methods listed by
   the server in any order.  This gives the server complete control over
   the authentication process if desired, but also gives enough
   flexibility for the client to use the methods it supports or that are
   most convenient for the user, when multiple methods are offered by
   the server.

So the client does have to choose. Looking into the ssh(1) man page of
OpenSSH, I find this:

   The methods available for authentication are: GSSAPI-based authentica-
   tion, host-based authentication, public key authentication, challenge-re-
   sponse authentication, and password authentication.  Authentication meth-
   ods are tried in the order specified above, though
   PreferredAuthentications can be used to change the default order.

And ssh_config(5) says:

   Specifies the order in which the client should try authentication
   methods.  This allows a client to prefer one method (e.g.
   keyboard-interactive) over another method (e.g. password).  The
   default is:

             gssapi-with-mic,hostbased,publickey,
             keyboard-interactive,password

I have no idea how popular it is to change the default order, which is
likely what most people expect.

/js

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