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

[Kent Watsen <[e-mail]>]

Hi Michal,

Thinning out resolved items below.

Thanks,
Kent


>>> But to fully configure the "keyboard-interactive" method, there is some more information needed. I have looked at how libssh and OpenSSH sshd(7) configure this method.
>>> 
>>> Starting with sshd, it relies on login or PAM [1]. I do not have any experience with PAM so I do not know how exactly that is supported in these YANG modules. But as for login, it seems to basically duplicate the functionality of the "password" authentication [2]. That is my experience as well but I do not know any more background for this. So, the configuration would again be simply a "password" leaf.
>>> 
>>> As for libssh, it went for a completely generic solution in which you must specify the method name (which maps to the "submethod" would be my guess), the instruction, and a list of challenge-response prompts [3]. We have implemented the simple password authentication this way [4], when the password is read from the system (the login functionality, actually). Going with this full configuration, the instruction and a list of challenge-response prompts (with echo configuration) should be added to "{grouping:ssh-server-grouping}/client-authentication/users/keyboard-interactive/submethod”.
>> 
>> I very much agree with modeling after how other well-known servers are configured.  One thing for sure, per-user passwords, public keys, and the like are NOT configured in sshd_config (they’re in a per-user directory, accessible via PAM, presumably).
>> 
>> Per auth method:
>> 
>>  - hostbased:
>>      - specifies all config via:
>>          - HostKey, HostKeyAlgorithms, and HostbasedAuthentication
>> 
>>  - password:
>>      - config just flags: PasswordAuthentication., PermitEmptyPasswords
>>      - but /etc/passwd typically used
>> 
>>  - publickey:
>>      - in sshd_config, a callout can be configured via AuthorizedKeysCommand
>>      - ...but ~/.ssh/authorized_keys typically used
>> 
>>  - keyboard-interactive
>>      - config just the flag KbdInteractiveAuthentication
>> 
>>  - gssapi
>>      - config just the flag GSSAPIAuthentication
>>      - apparently internally calls out to Kerboros on some systems
>> 
>>  - kerboros?
>>          - KerberosAuthentication
> 
> One can always rely on the system itself if the feature "client-auth-config-supported" is kept disabled.

True.

> But if enabled, all the information needed to configure an authentication method should be in the YANG module, right?

Yes.

> It seems to me that is how it is now, for all the previous methods, I tried to suggest what can be done for the "keyboard-interactive" method to be like that, too.

Okay, thanks.



>>> That is all the feedback I can provide for the "keyboard-authentication" method. I could even suggest the exact YANG changes if needed but I am missing the information about PAM support, if nothing else. Someone else could add something in case I missed anything and it would be great if you could find someone actually using the "gssapi" methods to provide similar feedback, otherwise you will likely have to rely on additional modules adding some augments, which is not an ideal solution.
>> 
>> Any suggestions you have would be good.
>> 
>> Honestly, I’m wondering if we should zero-out the "client-authentication’ and thereby force any consuming application to augment-in whatever config it thinks is needed…thoughts about that?
> 
> I think that could easily prevent interoperability and see no reason for that. You got this far, would be a shame to give up now :)

Okay.


> I have attached my changes that should allow to configure any "keyboard-interactive" authentication. The information should all be there but the descriptions may be too brief.

I’ve incorporated the changes here: https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0.

Note that this commit also removed the "supported-authentication-methods” container.

Questions:
  1) would you like you be added as a “Contributor”?
  2) should either “instruction” or “challenge” nodes be mandatory?
  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?

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.



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


K.