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

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

Hi Kent, 

> >>  3) should “ee-certs”/“ca-certs” be moved under the “user” node too?
> >>  4) is there a need to provide a similar “keyboard-interactive” update for the ssh-client?
> > 
> > To be honest, I did not look at this module previously because our CLI NETCONF client implementation is rather simple so we did not bother using this YANG module at all. But looking at it now, it seems to me it is the way I would expect it to be, all this new configuration is server-side only.
> 
> 
> In ietf.-ssh-client: should "leaf-list submethods” or "leaf-list oids” be ordered-by user?

Right, yes, I believe so.

> RELATED:  In iets-ssh-server: should any of “list submethod, “list prompt”, or "list gssapi-with-mic” be ordered-by user?

Reading through the RFCs again, I think all of these lists should actually be user-ordered, I missed that before. Moreover, if "list submethod" is user-ordered, the default submethod should simply be the first one and you can remove the "leaf default-submethod".

> > But, our NETCONF library does provide some additional configuration of the client SSH authentication so I will mention it and leave for you whether you want to add it into the modules or not. We support customizing the priority of each method so that there are no 'wasted' methods that only increase the authentication attempts. It seems that this is prevented in the SSH client module by all the "if-feature" on the individual methods, so that the unsupported ones can be disabled. But I think it may be useful for the client to be able to configure its preferred methods, in order, because you probably do not want to be bothered with the "password" authentication when you have a public key configured, for instance.
> 
> 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.

> >> On #3, this is likely mostly for me to resolve, but it seems to me that *all* client-auth details should be under the “user” node.  Yes, a bag-of-certs (or a single CA cert) could be used to auth a multiplicity of users, but having that reference configured per user (perhaps redundantly) is 1) more consistent and 2) better supports the server being able to produce a list of “productive method names” to return to the client.  Thoughts?
> >> 
> >> Separately, for background, I mentioned before that X.509-cert auth is a variation of the “publickey” authentication method.  RFC 4253, Section 6.6 clearly indicates this, as it consistently says "certificate or public key”, and RFC 6187, Section-2.1 likewise supports this.  So, we could push the whole “how to support X.509 formatted keys” into/under the “publickey” umbrella.   That said, it is way more natural for administrators to configure certs in their normal form then in the ssh-publickey form, hence why the ssh-client and ssh-server models have them broken out as they are.
> > 
> > But you do need to configure the public key for the user if you want to authenticate it by a certificate, right? Assuming so, I think it is fine the way it is but I do agree with your points and see no problems with the change you proposed, either way seems fine.
> 
> 
> If in your first question you mean an “X.509-based publickey”, then yes, but...
> 
> - if auth happens via an "ee-cert”, the ee-cert for each user needs to be configured, but it’s open as to if each user points to a specific ee-cert or if all users point to a bag of ee-certs.
> 
> - if auth happens via “ca-cert”, the same statements apply, but there is even less affinity, as typically a CA issues many EEs.

Yes, I understand, but I have too little experience with certificates and practical use-cases so I am not able to decide whether the certificate configuration can be only per-server or needs to be per-user.

> >>>>>> BTW, this introduces an issue as to if “client-identity-mappings” are required for SSH when certs are used, or if the SSH username that is built into the protocol (and used in al non-cert scenarios) should take precedence. Thoughts?
> >>>>> 
> >>>>> I have never configured or used certificates for SSH authentication so this is not a question that I can answer. But based on my other experience, I would naively guess that it means you are using certificates instead of SSH keys, which seems to me is relevant for the "hostbased" and "publickey" authentication methods and would, in-effect, replace the configuration of these methods. But that is not what is found in these YANG modules so I guess I am wrong.
> >>>> 
> >>>> X.509-based auth *is* a variation of “publickey” auth, so a “username” is still being passed in the SSH_MSG_USERAUTH_REQUEST message...
> >>> 
> >>> Right, it takes me some time to absorb all the implications. So what exactly is the purpose of "client-identity-mappings" for SSH? A client must always present its username when authenticating using SSH and it can be chosen so I do not see the point of changing the NETCONF session username based on the presented certificate and the cert-to-name mapping configuration. Am I missing something?
> >>> 
> >>> Actually, maybe I can think of a scenario. Supposing there are some NETCONF clients deployed that use SSH for authentication but want to identify users based on their certificates. Then there could be a single username always used for SSH authentication but the NETCONF client would map the specific certificate to a NETCONF username. That would allow the server, for example, to still implement NACM but effectively identify users only based on their certificates.
> >>> 
> >>> In this case your original question makes sense to me and I would see 2 solutions. Either there would have to be the expected SSH username configured in order for all the associated cert-to-name mappings to take effect or simply all the configured mappings would always be tried and if some is successful, the resolved username will always be used for NETCONF. I suppose a combination of this is also possible when the expected SSH username may or may not be configured.
> >> 
> >> 
> >> Digging into RFC 6187 again, I find this jewel:
> >> 
> >>   For the purposes of user authentication, the mapping between
> >>   certificates and user names is left as an implementation and
> >>   configuration issue for implementers and system administrators.
> >> 
> >> This is wild as is simultaneously suggests that a mapping (i.e. x509c2n:cert-to-name) may be needed while ignoring the fact that the “user name” is already being passed in the base SSH_MSG_USERAUTH_REQUEST message.
> >> 
> >> Popping this discussion back up to YANG models, ietf-netconf-server current has this snippet:
> >> 
> >>          container netconf-server-parameters {
> >>            description
> >>              "A wrapper around the NETCONF server parameters
> >>               to avoid name collisions.";
> >>            uses ncs:netconf-server-grouping {
> >>              refine "client-identity-mappings" {
> >>                if-feature "sshcmn:ssh-x509-certs";
> >>                description
> >>                  "Augments in an 'if-feature' statement
> >>                   ensuring the 'client-identity-mappings'
> >>                   descendent is enabled only when SSH
> >>                   supports X.509 certificates.";
> >>              } // FIXME: does an X.509-derived identity
> >>            }   //        override SSH username?
> >>          }
> >> 
> >> The questions are:
> >> 
> >>  1) are "client-identity-mappings” needed at all?
> >>  2) if “yes”, then do they override the base “user name” value?
> >> 
> >> For #1, I think you’re saying that flexibility is good and, for #2, RFC 6187 seems to be saying that it’s a matter of local policy.  Agreed?
> > 
> > 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.

Regards,
Michal