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

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

Hi Kent,

> > Still, I think we are pretty close now, from my perspective. As was discussed, the "keyboard-interactive" method is a completely generic one where the user is presented with a set of challenges and must correctly respond to them to pass the authentication. That should already work and the issue I was trying to solve is a security one, when the expected response is some sensitive information. Adding that, I think the configuration would be able to (safely) express all configurations that do not require any additional information (such as, I don't know, retrieving the expected response from some remote server). Incidentally, the expected response of the user password would also be supported.
> 
> The problem with the current keyboard-interactive model is that each “response” is effectively a password, even if it’s not a password, in that it is the magic answer that the client needs to provide.  
> 
> Thus, all the responses SHOULD be, e.g., hashed, so that the value that needs to be provided isn’t in the clear.  In this sense, we could use the iana:crypt-hash type for the “response” node, pushing it to the administrator to configure the hashed values.

That is true and would make sense.

> That said, if we’re leaning towards static/canned “keyboard-interactive” config being sold for, e.g., unit-testing, it would be easier on the administrator to leave the values in the clear.

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.

> >>> This is probably just a YANG modeling issue. I was already thinking about 1) and it seems to me it would make for a nice configuration data, but the YANG itself would be cluttered. Nevertheless, there may be a clean solution I am missing so it is up to you. We have simply assigned a priority to each authentication method, but I am not saying that is ideal.
> >> 
> >> #1 seems better at first but, assuming the list is called “authentication-method”, the immediate issue is what the “key” should be.  We’d have to introduce a somewhat artificial “name” node, which makes the approach less appealing.
> >> 
> >> #2 seems easy enough:
> >> 
> >>   leaf-list preferred-authentications {
> >>     type enumeration {
> >>       enum publickey { ... }
> >>       enum password { ... }
> >>       enum hostbased { ... }
> >>       ...
> >>     }
> >> 
> >> But new “enums” cannot be augmented into an “enumeration” (in case that is ever desired).  We could use “type string”, but that's too open.  Another option would be to define a hierarchy of identities and then have a leaf-list of identityrefs.  This could work, but...
> >> 
> >> Now I’m thinking to leave the order unspecified, since it’s a minor optimization (saving a round-trip), as the “none” option can be used to get a “productive methods” list from the server.
> >> 
> >> You said that you’d did this optimization before, but did it really matter, to save one roundtrip, especially in the context of using the keyboard-interactive method?
> >> 
> >> How about this for the the “client-identity” node’s description?
> >> 
> >>      "The credentials are unordered.  Clients may initially send
> >>        any configured method or, per RFC 4252, Section 5.2, send
> >>        the 'none' method to prompt the server to provide a list
> >>        of productive methods."
> > 
> > Like I said, the best example of a problem we were solving with these priorities was that when your SSH client has both "publickey" and "password" authentications supported and working and you connect to an SSH server that supports the "publickey" authentication, it is probably the method you prefer. I may be missing something but how do you solve this problem without some way of expressing these priorities explicitly? I do not see how getting the supported methods from the server will help you, it is strictly up to the client which of the methods it will select next (first).
> 
> I understand you’re trying to enable the client to know exactly the right auth mechanism to use first.  My last response was, effectively, “let’s NOT solve that problem, because it’s a minor optimization, saving just one round-trip."
> 
> 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.

Regards,
Michal