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

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

Second time I forgot so I'd rather send it now so that I do not forget again. It seems to me that "{grouping:ssh-server-grouping}/client-authentication" contains really sensitive information so I would expect it to have "nacm:default-deny-all;".

> Hi Kent,
> 
> > Hi Michal,
> > 
> > >>>>> An improvement I can think of is to put all the authentication methods in "users/user" in a mandatory choice. The authentication methods would be one case, while something like "global-config" (empty leaf, for example) would be the other. That should allow for maximum versatility when one could configure the 'global authentication methods', enable the "client-auth-config-supported" feature to configure the recognized users, but use the global authentication methods settings for some/all the users (not having to configure each one separately). Because that will probably be our use-case.
> > >>>> 
> > >>>> Could you provide a tree diagram snippet that illustrates this?  Regarding your last sentence, I imagine that that might be many folks use-case.  That is, the actual user-auth might be somewhere else (e.g., PAM, LDAP, etc.); it might be rare thing that folks would want to config users inside the “ssh-server-grouping”.
> > >>> 
> > >>> I wanted to, but quickly learned that I did not understand this YANG part correctly. It seems every client authentication method has its own feature AND a leaf or container in {grouping:ssh-server-grouping}/client-authentication/supported-authentication-methods that marks support for the authentication method, again. Why the redundancy?
> > >> 
> > >> The "{grouping:ssh-server-grouping}/client-authentication/supported-authentication-methods” container is solely for enabling the SSH-server know which authentication methods to present to the client during the handshake.
> > >> 
> > >> The "{grouping:ssh-server-grouping}/client-authentication/users” container is a locally-defined list of users and credentials that can be used to authenticate them.
> > >> 
> > >> In theory, the "supported-authentication-methods” could be derived as the union of the methods configured for each user, but at some point the “ca-certs” and “ee-certs” were pulled out of that container, and so that can’t be the case anymore…assuming it was ever a good idea in the first place...
> > > 
> > > I suppose I was not clear enough, the seeming redundancy is in all the specific client-authentication features AND the "supported-authentication-methods". You must both enable a feature and create the corresponding leaf/container to actually support the method.
> > > 
> > > But it seems enabled feature marks something like a capability of the system to support the authentication method and the data whether you actually want to advertise the method for new SSH clients.  I am not sure this distinction is needed, though.
> > 
> > The “feature” indicates if the server supports that configuration at all.  For instance, there may be an SSH server that only supports “publickey" or only X509 certs.  The feature gates what can be configured, long before a handshake.
> > 
> > 
> > > It seems to me the "supported-authentication-methods" container can be removed altogether and the advertised authentication methods will simply be all the configured ones for the user.
> > 
> > The "supported-authentication-methods” are to know what list of auth-methods to present to the SSH client during the handshake.  It would be ideal if this list could be derived from either “features” and as the union of the methods configured for each user.
> > 
> > Looking at RFC 4252, Section 5.1 (Responses to Authentication Requests) says:
> > 
> >    If the server rejects the authentication request, it MUST respond
> >    with the following:
> > 
> >       byte         SSH_MSG_USERAUTH_FAILURE
> >       name-list    authentications that can continue
> >       boolean      partial success
> > 
> >    The 'authentications that can continue' is a comma-separated name->    list of authentication 'method name' values that may productively
> >    continue the authentication dialog.
> > 
> >    It is RECOMMENDED that servers only include those 'method name'
> >    values in the name-list that are actually useful.  However, it is not
> >    illegal to include 'method name' values that cannot be used to
> >    authenticate the user.
> > 
> >    Already successfully completed authentications SHOULD NOT be included
> >    in the name-list, unless they should be performed again for some
> > 
> > 
> > 
> > And Section 5.2 (The "none" Authentication Request) says:
> > 
> >    A client may request a list of authentication 'method name' values>    that may continue by using the "none" authentication 'method name'.
> > 
> >    If no authentication is needed for the user, the server MUST return
> >    SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return>    SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of methods
> >    that may continue in its 'authentications that can continue' value.
> > 
> > 
> > So my reading is that the list of auth methods SHOULD be user-specific but MAY be (dare I say) feature-specific.  In either case, it seems that an explicit "supported-authentication-methods” may be too much.  I’m tempted to remove it...
> 
> Right, that is what I suggested, too. Based on the references it seems returning user-specific supported-authentication list is the best thing to do, anyway.
> 
> > >>> Regarding the client authentication configuration, which is a separate issue, I suppose the most generic solution would be to model it the same way certificates and some other things are. Meaning, to have a separate container with a list of client-authentication configurations. Then, every {grouping:ssh-server-grouping}/client-authentication/users/user will have to reference one. That should allow support for all kinds of scenarios, including one where there is only a single client-authentication configuration and all the users reference it.
> > >> 
> > >> This is where your providing a snippet of a tree diagram would be helpful.  Hopefully, with the above explanation, you're more able to do that now…?
> > > 
> > > I am sorry, I have still not adjusted to the fact that the modules now include all the configuration needed, with nothing being read from the system. Having understood this, I think the current principle of per-user configuration is fine, there is no other solution.
> > 
> > I’m unsure if “nothing being read from the system” is accurate.  Yes, this has been a thought, but I think it falls into two broad categories:
> > 
> > 1) per-user credentials (e.g., passwords in /client-authentication/users) 
> > 2) user-independent credential authenticators
> >       2a) configured PKI issuers (e.g., “ee-certs” and “ca-certs”)
> >       2b) configured callout mechanisms (e.g., PAM, LDAP, Radius, etc.)
> > 
> > Some comments:
> > 
> >   - we do not yet have anything in the model representing (2b)
> >   - (1) could always be viewed as something that should be provided by a (2b)
> 
> Thanks for the information, good to know.
>  
> > > 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. But if enabled, all the information needed to configure an authentication method should be in the YANG module, right? 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.
> 
> > > Actually, why is "keyboard-interactive" a list? A container should be fine and "submethods" should probably be a list instead.
> > 
> > Perhaps, but I was thinking that by it being a list, augments could vary by submethod.  I dunno how important that might be hough..
> > 
> > 
> > > 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 :) 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.
> 
> > > [1] https://linux.die.net/man/5/sshd_config (search for ChallengeResponseAuthentication)
> > > [2] https://www.freebsd.org/cgi/man.cgi?login.conf(5)#end (section AUTHENTICATION)
> > > [3] https://api.libssh.org/stable/group__libssh__server.html (function ssh_message_auth_interactive_request)
> > > [4] https://github.com/CESNET/libnetconf2/blob/master/src/session_server_ssh.c#L809
> > > 
> > >>>> The following regards the "tls-listen or tls-call-home or sshcmn:ssh-x509-certs” if-feature statement:
> > >>>>>> But I wasn’t trying to fix your original issue.  As mentioned, there is a YANG-next issue and the best that consuming modules can do is to 1) enable all the features defined in these modules and 2) augment-in “use”-specific feature statements where the groupings are used.
> > >>>>> 
> > >>>>> Okay, I suppose this can be done although it seems to me like a minor deviation (the augment solution). What is the reason for not having the module this way out-of-the-box?
> > >>>> 
> > >>>> It might be helpful to recall that this “if-feature” statement is in the netconf-client-server draft, and thus likely should be discussed in another thread.  That said, we’ve come so far already, so why not a little more, right?  ;)
> > >>>> 
> > >>>> So, do you have a proposal mind?
> > >>> 
> > >>> Right, we are getting OT, too bad :) I have attached a diff that fixes my concerns and I think it also makes for a more intuitive tree diagram.
> > >> 
> > >> Your diff points in a direction that looks good to me.   I wish you’d proposed it originally ;)
> > >> 
> > >> How does this commit look?  https://github.com/netconf-wg/netconf-client-server/commit/29523cfb2a8561c578fad7aaf36107bc7ecd5afb
> > > 
> > > Um, I do not think that works. It took me a while to understand but based on the comment, you tried to add the "sshcmn:ssh-x509-certs" if-feature to the "client-identity-mappings" container. To my knowledge, what you actually did was augment-in no new nodes to the "client-identity-mappings" container, but making 'all these no nodes' conditional on an if-feature, none of which makes sense. The "if-feature" in an augment relates to the "augment" itself, not to its target, you can only add new nodes with an augment.
> > 
> > 
> > Oh bother, the whole “augment” vs. “refine” mixup again, here’s the fix:
> > 
> > https://github.com/netconf-wg/netconf-client-server/commit/f81d0c5b0a3361a4903b87c9777c33b1d143975c
> 
> Seems okay now.
> 
> > >> 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.
> 
> Regards,
> Michal