Re: [Netconf] ?==?utf-8?q? ietf-netconf-server and ietf-ssh-server draft module

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

Hi Kent,
my comments are inline.

On Wednesday, August 3, 2016 00:35 CEST, Kent Watsen <[e-mail]> wrote: 
 
> 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?

Right, I have forgotten about this other module, now it makes sense. As for client-cert-auth, we do not support X.509 certificates for SSH, so I will not be implementing this and do not really know any details of it. Based on what I have just read (RFC 6187) I have understood that certificates replace only the public key (which is actually quite obvious looking at the .../host-key/type choice), 1) so no cert-to-name is necessary. But additionally, the server must verify the certificate the standard TLS-like way (go up the whole cert chain), so there must also be this information. I guess 2) is not a bad idea if we want to keep it consistent, but it also disorganizes things a bit (for one action, verifying the certificate chain, you need to look at 2 different places/modules). The situation is similar to ietf-system and authorized SSH public keys, so this is likely necessary, but I definitely agree that a reference to the other module should be included.

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

OK, so it should work like this. The server first looks through all the host-keys, collects information about all the used key algorithms and sends it. When the algorithm negotiation is finished, server uses the key agreed upon (if several keys use the same algoithm, the one with the highest priority is used, BTW is support for this really needed, to allow more keys for an algorithm?). Also, to my knowledge, server host keys are private keys, so maybe rename .../hostkey/type/public-key? Still, some description of what is expected of this configuration to affect (something like the first sentences in this paragraph) would be helpful.
    
>     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
> 
> 

Regards,
Michal