Re: [Netconf] ietf-netconf-server and ietf-ssh-server draft module

[Kent Watsen <[e-mail]>]

Hi Michal,

    Hi, during first implementation steps of this module I noticed some issues, which may or may not be relevant, but I would like to receive some feedback.
    
[KENT] Again, it’s great to see that you’re trying to use this module.  Implementations are what’s needed to prove everything works.


    Regarding the subtree /netconf-server/listen/endpoint/ssh, there is no configuration of known and accepted client SSH public keys during NETCONF server SSH authentication. There is a list of trusted-ssh-host-keys in ietf-system-keychain module for NETCONF client verification of server keys, why not the other way around? In our NETCONF server we used a list of pairs of trusted client SSH keys with their username (sort-of like simplified cert-to-name on SSH keys instead certificates) and it worked well.

[KENT] Currently the expectation is that admin accounts are configured via the ietf-system module [RFC 7317].   This module enables the configuration of ssh public keys for client-auth (see /system/authentication/user/authorized-key).   I think that this separation is fine as it is mimics SSH using PAM.  Of course, then you might wonder about /netconf-server/listen/endpoint/ssh/client-cert-auth, such as 1) why doesn’t it have a “cert-maps” structure like tls-listen or 2) should the client’s X.509 cert be augmented into /ietf-system:system/authentication/user/?   Something isn’t right here, but I haven’t decided on a fix yet - any suggestions?  Additionally, it seems that this section should say something about its interaction with RFC 7317, agreed?


    Next, I am unsure about the host-keys/host-key list (relative to the container from the previosu paragraph) meaning, In the description it says that it is used for announcing the supported key algorithms. So these keys are not used as SSH server host keys (whose digest is sent to SSH clients)? If so, why is the configuration of these host keys missing?

[KENT] These are indeed the server’s SSH host-keys, but in the SSH protocol, the name of the algorithm for the host-key is sent first.  So, for instance, if the configured host key happened to be an X.509v3 certificate with 2048 RSA and SHA256, then the server would send the algorithm name “x509v3-rsa2048-sha256” (from RFC 6187).   Perhaps the text can be improved?

    
    Lastly, I have noticed that in the list /netconf-server/listen/endpoint/ssh/host-keys/host-key, the name leaf is mandatory even though it is a key, while the choice type is not and I believe it should be. Perhaps a misplaced mandatory?

[KENT] Indeed, and I have fixed this in my local copy, thanks!


    Regards,
    Michal Vasko
    
Thanks,
Kent