Re: [netconf] Latest ietf-netconf-server draft and related modules

[Kent Watsen <[e-mail]>]

Hi Michal,

>> My understanding that you “think" these updates are okay, which is greatly appreciated (your considerations, that is).   It would be perfect if you could actually try them out before this work gets published...
> 
> Yes, that is exactly what I meant. Unfortunately, I am terribly busy and I am just not able to implement all these modules. Even if they got published today, I think it would take us at least several months till we are able to use them.

Noted.


>>> An improvement I can think of is to put all the authentication methods in "users/user" in a mandatory choice. The authentication methods would be one case, while something like "global-config" (empty leaf, for example) would be the other. That should allow for maximum versatility when one could configure the 'global authentication methods', enable the "client-auth-config-supported" feature to configure the recognized users, but use the global authentication methods settings for some/all the users (not having to configure each one separately). Because that will probably be our use-case.
>> 
>> Could you provide a tree diagram snippet that illustrates this?  Regarding your last sentence, I imagine that that might be many folks use-case.  That is, the actual user-auth might be somewhere else (e.g., PAM, LDAP, etc.); it might be rare thing that folks would want to config users inside the “ssh-server-grouping”.
> 
> I wanted to, but quickly learned that I did not understand this YANG part correctly. It seems every client authentication method has its own feature AND a leaf or container in {grouping:ssh-server-grouping}/client-authentication/supported-authentication-methods that marks support for the authentication method, again. Why the redundancy?

The "{grouping:ssh-server-grouping}/client-authentication/supported-authentication-methods” container is solely for enabling the SSH-server know which authentication methods to present to the client during the handshake.

The "{grouping:ssh-server-grouping}/client-authentication/users” container is a locally-defined list of users and credentials that can be used to authenticate them.

In theory, the "supported-authentication-methods” could be derived as the union of the methods configured for each user, but at some point the “ca-certs” and “ee-certs” were pulled out of that container, and so that can’t be the case anymore…assuming it was ever a good idea in the first place...


> Regarding the client authentication configuration, which is a separate issue, I suppose the most generic solution would be to model it the same way certificates and some other things are. Meaning, to have a separate container with a list of client-authentication configurations. Then, every {grouping:ssh-server-grouping}/client-authentication/users/user will have to reference one. That should allow support for all kinds of scenarios, including one where there is only a single client-authentication configuration and all the users reference it.

This is where your providing a snippet of a tree diagram would be helpful.  Hopefully, with the above explanation, you're more able to do that now…?



>> The following regards the "tls-listen or tls-call-home or sshcmn:ssh-x509-certs” if-feature statement:
>>>> But I wasn’t trying to fix your original issue.  As mentioned, there is a YANG-next issue and the best that consuming modules can do is to 1) enable all the features defined in these modules and 2) augment-in “use”-specific feature statements where the groupings are used.
>>> 
>>> Okay, I suppose this can be done although it seems to me like a minor deviation (the augment solution). What is the reason for not having the module this way out-of-the-box?
>> 
>> It might be helpful to recall that this “if-feature” statement is in the netconf-client-server draft, and thus likely should be discussed in another thread.  That said, we’ve come so far already, so why not a little more, right?  ;)
>> 
>> So, do you have a proposal mind?
> 
> Right, we are getting OT, too bad :) I have attached a diff that fixes my concerns and I think it also makes for a more intuitive tree diagram.

Your diff points in a direction that looks good to me.   I wish you’d proposed it originally ;)

How does this commit look?  https://github.com/netconf-wg/netconf-client-server/commit/29523cfb2a8561c578fad7aaf36107bc7ecd5afb

BTW, this introduces an issue as to if “client-identity-mappings” are required for SSH when certs are used, or if the SSH username that is built into the protocol (and used in al non-cert scenarios) should take precedence.  Thoughts?

K.