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

[Kent Watsen <[e-mail]>]

Hi Michal,



>> 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.
> 
> Great, thanks. Connected to the separate NACM-related question, the most common way of configuring the keyboard-interactive authentication is to request the user password, which would have to be stored in clear-text now. To cover it, you could replace the "response" leaf by a choice with "answer" string leaf and "password" ianach:crypt-hash leaf, for example. And leave some other possible specific responses for augments.

I don’t doubt you, but already SSH (* see below) allows for a multiplicity of authentication methods so, e.g., “publickey password keyboard-interactive” would mean that the client must first pass “publickey”, then “password”, and finally “keyboard-interactive”.  My point is that, if a password is to be asked for, wouldn’t the “password” method be preferably used, and hence the existing "ianach:crypt-hash” protection suffice?  

That said, I’m not against converting the “leaf” to a “choice with a single ‘cleartext’ leaf” case if you think it’s better...

* The sshd_config manage says:

    AuthenticationMethods
             Specifies the authentication methods that must be successfully completed for a user to be granted access.  This
             option must be followed by one or more lists of comma-separated authentication method names, or by the single
             string any to indicate the default behaviour of accepting any single authentication method.  If the default is
             overridden, then successful authentication requires completion of every method in at least one of these lists.

             For example, "publickey,password publickey,keyboard-interactive" would require the user to complete public key
             authentication, followed by either password or keyboard interactive authentication.  Only methods that are next in
             one or more lists are offered at each stage, so for this example it would not be possible to attempt password or
             keyboard-interactive authentication before public key.


As yet, with the current model, I don’t see a direct correlation to “AuthenticationMethods”, unless you think “keyboard-interactive” is it, but that doesn’t follow from the manpage snippet above.






> 
>> Questions:
>>  1) would you like you be added as a “Contributor”?
> 
> That is up to you, I am fine either way.

Added.



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

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


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



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



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

Correct?


K.