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

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

Hi Kent,

starting with the issue of the exact purpose of all these modules, I may have misunderstood. It seemed to me they are meant to fully configure an SSH server/client, NETCONF server/client, ... With the limitation of leaving out some rare or too complex use-cases up to augments. At least that is what I was trying to help you with, but these criteria are subjective, of course.

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.

More below.

> >> The ssh_config manage has:
> >> 
> >>    PreferredAuthentications
> >>            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
> >> 
> >> We could support this either by:
> >> 
> >> 1) wrap everything inside an “ordered-by user” list
> >> 
> >> 2) define a “PreferredAuthentications” like variable, to provide an external ordering
> >> 
> >> Thoughts?
> > 
> > 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).

> >>> For #1 I came up with a possible scenario when the "client-identity-mappings" could possibly have their use. If the scenario is unlikely to be used in practice or simply not relevant for some reason and you (or anyone else) are not able to come up with any other, I think these mappings are not needed. Just a note, we do not and not plan to support the scenario.
> >> 
> >> Ack, and we shouldn't support a low-probability use-case.
> >> 
> >> 
> >>> As for #2, I think I have suggested a way to allow configuring it either way so that the 'local policy' can be directly configured. And that would probably be the best solution.
> >> 
> >> I think what you are saying is:
> >> 
> >> 1) if a cert-to-name mapping is NOT found, then fallback to the SSH-level username
> >> 
> >> 2) if a cert-to-name mapping IS found, then it SHOULD override the SSH-level username.
> > 
> > If you decide to keep this mappings, I was suggesting a completely generic solution when you could configure a specific username for the cert-to-name mappings.
> > 
> > 1) If the user name is configured and
> > a) matches the SSH user name, you try to use the mapping and override the SSH user name.
> > b) does not match the SSH user name, you ignore this mapping.
> 
> > 2) If the user name is not configured, you always try to use the mapping.
> > 
> > But there is still the question of what to do if you find no matching mapping. I suppose it could be a separate configuration leaf deciding whether you want to fall back on the SSH user name or fail the authentication altogether.
> 
> Added that mappings override the SSH-level username.
> 
> Added a separate configuration leaf for if a mapping is *required*

So you have decided to keep it? In any case, its functionality should now be unambiguous.

Regards,
Michal