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

[Kent Watsen <[e-mail]>]

Hi Michal,

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

 

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


K.