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

[Kent Watsen <[e-mail]>]

Hi Juergen,


> On the SSH server side, we have this:
> 
>       |  +-- users {client-auth-config-supported}?
>       |  |  +-- user* [name]
>       |  |     +-- name?          string
>       |  |     +-- public-keys! {client-auth-publickey}?
>       |  |     |  +---u ts:local-or-truststore-public-keys-grouping
>       |  |     +-- password?      ianach:crypt-hash
>       |  |     |       {client-auth-password}?
>       |  |     +-- hostbased! {client-auth-hostbased}?
>       |  |     |  +---u ts:local-or-truststore-public-keys-grouping
>       |  |     +-- none?          empty {client-auth-none}?
>       |  +-- ca-certs!
>       |  |       {client-auth-config-supported,sshcmn:ssh-x509-certs}?
>       |  |  +---u ts:local-or-truststore-certs-grouping
>       |  +-- ee-certs!
>       |          {client-auth-config-supported,sshcmn:ssh-x509-certs}?
>       |     +---u ts:local-or-truststore-certs-grouping
> 
> On the TLS side, we have this:
> 
>       +-- client-authentication! {client-auth-config-supported}?
>       |  +-- ca-certs! {x509-certificate-auth}?
>       |  |  +---u ts:local-or-truststore-certs-grouping
>       |  +-- ee-certs! {x509-certificate-auth}?
>       |  |  +---u ts:local-or-truststore-certs-grouping
>       |  +-- raw-public-keys! {raw-public-key-auth}?
>       |  |  +---u ts:local-or-truststore-public-keys-grouping
>       |  +-- psks?              empty {psk-auth}?
> 
> On the HTTP side, we have this:
> 
>       +-- client-authentication! {client-auth-config-supported}?
>          +-- users
>             +-- user* [user-id]
> 		+-- user-id?       string
> 		+-- (auth-type)?
>                   +--:(basic)
>                      +-- basic {basic-auth}?
>                         +-- user-id?    string
>                         +-- password?   ianach:crypt-hash
> 
> What exactly is the problem?

Right now, the question at hand is to what we do with the built-in “user” lists in the SSH and HTTP server models.  

I don’t use them in my application, but it seems that 1) having something simple (e.g., htpasswd-like) might help some and 2) they can be optionally implemented/enabled, so it doesn’t hurt to leave them in.  

I’m a fan for just tying up the loose ends Michal is raising, but I thought you were advocating something else?


> a) Is the issue that there is no support for keyboard-interactive in
>   the SSH model?

There is now per this commit: https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0 <https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0>

An updated draft will be posted once we get past yours and Michal's comments. 


> b) Is the issue that there is no support for non-local user databases
>   for SSH and HTTP authentication?

If we think that is important, yes.  The current “solution” for non-local user databases is 1) don’t enable "client-auth-config-supported” and 2) augment-in what is needed for the application…and maybe 3) only use TLS, where the truststore/keystore + cert-to-name obviate the need for a user database.



> Personally, I would be fine to go ahead with these limitations as long
> as we have the structure in place to add things later (e.g., once
> vendors have prototyped extensions paving the way to a standard
> solution).

Okay, I think we’re aligned in this regard.  As mentioned above, the various "client-authentication” nodes don’t have to be implemented, so more complete solutions come in the future.


K.