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

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

Hi Kent,

> > I do not really see the point of having the configuration there just for testing purposes. With all the feedback provided, it seems to me now that all the configuration of "keyboard-interactive" should be scratched and leave it just as a presence container to allow augments. With a description mentioning them and the possibility of using PAM or similar authentication methods.
> 
> Could provide how you used “keyboard-interactive” before?  Was config such as in the current model used, or was it actually interacting with an PAM-like mechanism?

Currently, we do not use PAM but directly ask for the user password for the "keyboard-interactive" method. But it seems to me this may be wrong and definitely not the intended use so I will probably rewrite it once these modules are published and we are migrating to them.

> >> My question before was (and still is), since you did this optimization before, did it really matter (to save that roundtrip), especially in the context of using the (very slow) keyboard-interactive method?
> > 
> > But how is it saving just one round-trip? If you are offered "password" authentication but want to use "publickey" instead, let's say, you will likely leave the input empty just so that it fails and you get to the next method. But that causes a failed authentication attempt, if nothing else, which I do not think is that harmless.
> 
> I’m unsure if you understand the SSH protocol, so here goes:  the client starts off with an auth method.  It can optimistically pick one (e.g., if it only has one to choose, then it has nothing to lose by picking it) or pick “none”.   In either case, if the server is unhappy with the method selected by the client (and it always will be when “none” is selected), the server responds with a list of “productive” methods the client should try next.  
> 
> 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.

Regards,
Michal