[Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

[Balázs Kovács <[e-mail]>]

Hi All,

I made an attempt to make use of the ietf-ssh-client@2018-06-04 module to configure an interactive ssh client, and I found some obstacles. The current ietf-ssh-client model has the following structure:

module: ietf-ssh-client
  +--rw client
     +--rw client-identity
     |  +--rw username?            string
     |  +--rw (auth-type)
     |     +--:(password)
     |     |  +--rw password?      string
     |     +--:(public-key)
     |     |  +--rw public-key
     |     +--:(certificate)
     |        +--rw certificate {sshcmn:ssh-x509-certs}?
     +--rw server-auth
     |  +--rw pinned-ssh-host-keys?   ta:pinned-host-keys-ref
     |  +--rw pinned-ca-certs?        ta:pinned-certificates-ref {sshcmn:ssh-x509-certs}?
     |  +--rw pinned-server-certs?    ta:pinned-certificates-ref {sshcmn:ssh-x509-certs}?
     +--rw transport-params {ssh-client-transport-params-config}?

In the netconf-client module, which I took as example it is mounted to the 'ssh' container and preceded by:

   module: ietf-netconf-client
     +--rw netconf-client
        +--rw initiate! {initiate}?
        |  +--rw netconf-server* [name]
        |     +--rw name                  string
        |     +--rw endpoints
        |     |  +--rw endpoint* [name]
        |     |     +--rw name         string
        |     |     +--rw (transport)
        |     |        +--:(ssh) {ssh-initiate}?
        |     |        |  +--rw ssh
        |     |        |     +--rw address?            inet:host
        |     |        |     +--rw port?               inet:port-number\

In the case of the interactive client, I want some limited parameters to be provided by the invoking user, which is at least the target user, target address, and target port, so  I would not need all the data nodes present in the netconf-client, but I need a subset of them, including the user credentials. The problem I face, is that for one target address, the user can select multiple target users, and for one target user, it should be able to select multiple target addresses. With the above model, if I want to set up a second client identity, I would basically need to create a complete endpoint with the same data in all the rest of the data nodes. Equally, if I want to set up a different endpoint, I need to copy all the possible client identities to be able to use them at other target addresses.

My thinking is that the endpoint related configuration (address, port, server-auth, transport-params) should be decoupled from client identities, so I can set them up and mount them independently.  However, I think this would effect the ssh-client grouping a bit heavily, basically breaking it up into two pieces. One that caters for the client identity, and another for the endpoint/server security.

One looking like this (temp name 'ssh-client-client-identity-grouping'):


     grouping ssh-client-client-identity-grouping

       +-- client-identity

          +-- username?            string

          +-- (auth-type)

             +--:(password)

             |  +-- password?      string

             +--:(public-key)

             |  +-- public-key

             |     +---u ks:local-or-keystore-asymmetric-key-grouping

             +--:(certificate)

                +-- certificate {sshcmn:ssh-x509-certs}?

                   +---u ks:local-or-keystore-end-entity-certificate-grouping


And another (temp name 'ssh-server-auth-transport-params-grouping'):





     grouping ssh-client-server-auth-transport-params-grouping

       +-- server-auth

       |  +-- pinned-ssh-host-keys?   ta:pinned-host-keys-ref

       |  +-- pinned-ca-certs?        ta:pinned-certificates-ref

       |  |       {sshcmn:ssh-x509-certs}?

       |  +-- pinned-server-certs?    ta:pinned-certificates-ref

       |          {sshcmn:ssh-x509-certs}?

       +-- transport-params {ssh-client-transport-params-config}?

          +---u sshcmn:transport-params-grouping



I also wonder if this would effect the similar module of tls-client. In TLS case, the client identity used is more bound to actual server and is rarely selectable by interaction, but splitting the current single grouping into two may probably not harm either.

Best Regards,
Balazs