Subject: [Netconf] Quick review of draft-ietf-netconf-ssh-client-server-01

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 15 Nov 2016 08:10:14 +0000

I am not a YANG expert as I am more on the security side of our industry, so, bear with my comments.

listening-ssh-client-grouping: if I read the YANG correctly, then there is no list of <address, port> tuples but rather a list of <address> and a lot of <port> which is not correct.

May I also assume that inet:ip-address can be IPv4, IPv6 as well as FQDN ?

trusted-ssh-host-keys should be matched with a FQDN or an IP address and not simply listed with being associated to a server.

Username to be used should optionally be linked to a trusted server

Ciphers and MAC to be used should also be part of the model IMHO.

Then, for specific connections:

Missing configuration items for SSH clients include: SSH version (1 or 2 or any) or is v2 assumed?

Compression can also be configured for SSH and does not appear in the YANG model.

What about SSH tunnels?

On the server, there is a list of trusted client certificates but not a list of trusted client public keys.

Hope this helps

-éric

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Nov 2016 00:24:21 +0000

Hi Eric,

Thank you for your review.  FWIW, you caught that particular draft in a known-incomplete state, both because the fallout from the keystore split is still being propagating, as well as because the ‘client’ model is all new and somewhat volatile (IMO), compared to the ‘server’ model.  Nonetheless, please see my comments below.

Thanks,
Kent

From: Netconf <[email-masked]> on behalf of "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tuesday, November 15, 2016 at 5:10 PM
To: "[email-masked]" <[email-masked]>
Subject: [Netconf] Quick review of draft-ietf-netconf-ssh-client-server-01

KENT> There isn’t a list here, there is just one address and one port, as it represents a single endpoint.  It is intended that this grouping to be used by other models, perhaps in a list.  Indeed, this is exactly what is done in draft-ietf-netconf-netconf-client-server-01.

KENT> FWIW, a ‘grouping’ statement is itself not a protocol accessible node, it needs to be ‘used’ in another model.  To point, this draft is defining a generic model for SSH clients, not the configuration for a specific SSH client like the OpenSSH client.

KENT> yes, inet:ip-address is defined in RFC 6991 as supporting both v4 and v6 addresses.

KENT> I agree, but I also think that this is covered in the existing model.  That is, if you look at it, trusted-ssh-host-key is a ‘leafref’ to /ks:keystore/trusted-ssh-host-keys/name.  That is, it references one of many bags of host keys in the keystore.  If desired, one could configure a bag-per-client or let more than one client reference the same bag.  Note, here I use ‘bag’ loosely as per PKCS#7.

KENT> are you referring to user-auth-credentials?  I’m not 100%, but I think that this is indeed what the model is doing.  Can you look again at it?

KENT> I think that you’re right about this.  currently we’re focusing on the core aspects, but it does make sense that it would extend to ciphers and macs, as they’re also in the realm of a generic ssh client.

KENT> the draft doesn’t say, which is a problem. I just as well assume to start with v2.  What do you think?

KENT> true, same issue as ciphers and macs.

What about SSH tunnels?

KENT> hmmm, I wonder if this goes too far outside the scope of a generic ssh client.  Maybe this is better modeled by a specific SSH client model?

KENT> good catch, thanks!

Thanks again,

Kent

Hope this helps

-éric