Re: [netconf] why did we breakout the groupings?

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

Hi Kent,

We had the attached conversation.

Since we had this change, I admit I refrained from using the client-identity-grouping separately from an endpoint configuration (see attached mail). Allowing the option for interactive selection of client identity did not seem to be that good idea after all. I cannot say now I have any intention to use them separately in the close future.

>From your feedback I so far understood that these sub-grouping do not harm much since the client-server models can use the original grouping, such as the 'ssh-client-grouping'.

All in all, I think I do not mind if you collapse this back into a single grouping if there is no other need to keep them separate.

Br,
Balazs



From: Kent Watsen <[e-mail]>
Sent: Thursday, March 21, 2019 3:54 PM
To: Balázs Kovács <[e-mail]>
Cc: [e-mail]
Subject: why did we breakout the groupings?

Hi Balazs,

I'm in the middle of answering your other question when I was reminded that I've been meaning to follow up with you on this issue...

Can you please help me recall why several months back we made the decision to redefine the ietf-ssh-[client/server]-grouping statements to use other groupings?  For instance, here's the current definition:

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

Obviously it was because you (I think it was you) wanted to be able to "use" the inner grouping in another context, but why?

I ask because this strategy is percolating into all of the client/server models and it seems weird, if not wrong.  I currently have it as an "open issue" in my presentation for Monday, but I'd rather resolve it offline/now if possible.

Kent // contributor

--- Begin Message ---

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 <[e-mail]>
Sent: Thursday, August 30, 2018 1:59 AM
To: Balázs Kovács <[e-mail]>; [e-mail]
Subject: Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

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" <[e-mail]<mailto:[e-mail]>> wrote:

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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, August 27, 2018 9:42 PM
To: Balázs Kovács <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

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" <[e-mail]<mailto:[e-mail]>> wrote:

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 <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, August 25, 2018 12:39 AM
To: Balázs Kovács <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Netconf] ietf-ssh-client@2018-06-04, issues with the grouping

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" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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

--- End Message ---