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

From: Kent Watsen <[email-masked]>
Date: Fri, 24 Aug 2018 22:38:42 +0000

Hi Balazs,

Why have configuration for an "interactive client" at all?   Is this an app that can launch an interactive connection using previously configured client credentials?  If so, then I think I understand the problem; the use case seems rather different than the use case that is currently being solved.

I understand the desire to have a YANG module to capture your config, and I understand the desire for that module to be able to make use of groupings defined in the ietf-ssh-client.

If the request is to expose a couple groupings, but otherwise leave the model unchanged, then I can see how that might be done.  But if the request is to change e.g., ssh-client-grouping, to support a decoupling of client credentials, then I don't see how to do that.

Kent // contributor

On 8/24/18, 10:14 AM, "Netconf on behalf of Balázs Kovács" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Balázs Kovács <[email-masked]>
Date: Mon, 27 Aug 2018 07:49:03 +0000

Hi Kent,

It is as you say, an app that can launch an interactive connection using previously configured client credentials, host authentication, and transport params.

My request or question would be if the current single grouping called ‘ssh-client-grouping’ could be split into two: one that only includes the ‘client-identity’ definition, and another which includes ‘server-auth’ and ‘transport-params’. I think this change would enable better flexibility for re-use in case of any SSH-based applications, and the only impact on the existing modules using ssh-client-grouping would be to use two groupings from now on instead of one.

Just to recap the use case, my intention would be to be able to mount a client identity into a list and into a container that is independent of the actual endpoint (for example, as defined in netconf-client /netconf-client/netconf-server/endpoints/endpoint) being used. Which identity is to be used is selected by interaction with the SSH client (e.g., via action parameter).

What do you think?

Br,
Balazs

From: Kent Watsen <[email-masked]>
Sent: Saturday, August 25, 2018 12:39 AM
To: Balázs Kovács <[email-masked]>; [email-masked]
Subject: Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

Hi Balazs,

Kent // contributor

Hi All,

module: ietf-ssh-client
  +--rw client
     +--rw client-identity
     |  +--rw username?            string
     |  +--rw (auth-type)
     |     +--:(password)

       +-- client-identity

          +-- username?            string

          +-- (auth-type)

             +--:(password)

             |  +-- password?      string

             +--:(public-key)

             |  +-- public-key

             +--:(certificate)

       +-- server-auth

Best Regards,
Balazs

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 Aug 2018 19:41:38 +0000

Assuming your two groupings below, or something close to them, we could redefine the existing "ssh-client-grouping" to the following:

  grouping ssh-client-grouping {
    uses ssh-client-client-identity-grouping;
   uses ssh-client-server-auth-transport-params-grouping;
  }

The net-result is no change to the model, but now the inner groupings can be repurposed.  Is this your proposal?

Kent // contributor

On 8/27/18, 3:49 AM, "Balázs Kovács" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

What do you think?

Br,
Balazs

Hi Balazs,

Kent // contributor

Hi All,

module: ietf-ssh-client
  +--rw client
     +--rw client-identity
     |  +--rw username?            string
     |  +--rw (auth-type)
     |     +--:(password)

       +-- client-identity

          +-- username?            string

          +-- (auth-type)

             +--:(password)

             |  +-- password?      string

             +--:(public-key)

             |  +-- public-key

             +--:(certificate)

       +-- server-auth

Best Regards,
Balazs

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 28 Aug 2018 09:42:44 +0000

Hi Kent,

Yes, this would be my proposal. Would similar change to ietf-tls-client would be applicable? I don’t have the same interactive use case for TLS, but maybe having this flexibility (the 2 new groupings) could be beneficial for TLS too.

Br,
Balazs

From: Kent Watsen <[email-masked]>
Sent: Monday, August 27, 2018 9:42 PM
To: Balázs Kovács <[email-masked]>; [email-masked]
Subject: Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

Kent // contributor

Hi Kent,

What do you think?

Br,
Balazs

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, August 25, 2018 12:39 AM
To: Balázs Kovács <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

Hi Balazs,

Kent // contributor

Hi All,

module: ietf-ssh-client
  +--rw client
     +--rw client-identity
     |  +--rw username?            string
     |  +--rw (auth-type)
     |     +--:(password)

       +-- client-identity

          +-- username?            string

          +-- (auth-type)

             +--:(password)

             |  +-- password?      string

             +--:(public-key)

             |  +-- public-key

             +--:(certificate)

       +-- server-auth

Best Regards,
Balazs

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Aug 2018 23:58:43 +0000

Hi Balazs, All,

I made the change in my local copy, but note that I also separated server-auth
and transport-params.   Below is an example, is it okay?

   grouping ssh-client-grouping {
      description
        "A reusable grouping for configuring a SSH client without
         any consideration for how an underlying TCP session is
         established.";
     uses client-identity-grouping;
      uses server-auth-grouping;
      uses transport-params-grouping;
    }

I made the change to all four of the groupings: [ssh|tls]-[client|server]-grouping.

PS: soon I'll be posting an update to all these drafts so folks can see the updates
       made since the IETF 102 presentation.

Kent

On 8/28/18, 5:42 AM, "Balázs Kovács" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Br,
Balazs

Kent // contributor

Hi Kent,

What do you think?

Br,
Balazs

Hi Balazs,

Kent // contributor

Hi All,

module: ietf-ssh-client
  +--rw client
     +--rw client-identity
     |  +--rw username?            string
     |  +--rw (auth-type)
     |     +--:(password)

       +-- client-identity

          +-- username?            string

          +-- (auth-type)

             +--:(password)

             |  +-- password?      string

             +--:(public-key)

             |  +-- public-key

             +--:(certificate)

       +-- server-auth

Best Regards,
Balazs

---

From: Balázs Kovács <[email-masked]>
Date: Thu, 30 Aug 2018 09:11:11 +0000

Hi Kent,

Looks good and it is also good that you added the same structure to all four of those ssh/tls groupings.

Br,
Balazs

From: Kent Watsen <[email-masked]>
Sent: Thursday, August 30, 2018 1:59 AM
To: Balázs Kovács <[email-masked]>; [email-masked]
Subject: Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

Hi Balazs, All,

Kent

Hi Kent,

Br,
Balazs

Kent // contributor

Hi Kent,

What do you think?

Br,
Balazs

Hi Balazs,

Kent // contributor

Hi All,

module: ietf-ssh-client
  +--rw client
     +--rw client-identity
     |  +--rw username?            string
     |  +--rw (auth-type)
     |     +--:(password)

       +-- client-identity

          +-- username?            string

          +-- (auth-type)

             +--:(password)

             |  +-- password?      string

             +--:(public-key)

             |  +-- public-key

             +--:(certificate)

       +-- server-auth

Best Regards,
Balazs