Re: [netconf] update to ssh-server draft

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

Hi Kent,

I have some difficulties in understanding the intent of the changes you describe.

In ietf-ssh-server@2019-11-20:

       |  +-- supported-authentication-methods

       |  |  +-- publickey?   empty

       |  |  +-- passsword?   empty

       |  |  +-- hostbased?   empty

       |  |  +-- none?        empty

       |  |  +-- other*       string


Why do we bother with the 'none' and the 'other' methods? 'none' is not recommended, and 'other' is just simply unknown.

'password' and 'publickey' authentication configuration is described by RFC7317. I would then expect reusable (local) definitions to be created in RFC7317, and until then maybe we should not bother with copying that to the ssh-server model. Do you really foresee that the system authentication model cannot be used for SSH?


Implementing 'hostbased' could maybe make sense. I assume that requires the use of 'local-or-truststore-host-keys-grouping' under some username so that the mapping between key and users can be done (as you suggested before). The users which are defined here could be authenticated with hostkeys on top of the RFC7317 users (which can login with pwd or pubkey).



I also don't understand the point in having the feature 'client-auth-config-supported'. The TLS groupings don't have this, and also where would the configuration of ca-certs, client-certs, etc. be if not in this server grouping?



Br,

Balazs



From: Kent Watsen <[e-mail]>
Sent: Friday, November 22, 2019 4:49 PM
To: Balázs Kovács <[e-mail]>
Cc: [e-mail]
Subject: Re: update to ssh-server draft

Hi Balazs,

The new local configuration in ssh-server draft seem to have some not appropriate terminology. The public key of the users should be maybe not called host keys?

Correct.  Martin raised this point on the 13th too (subject: "client identification in ietf-netconf-server")



 In RFC7317:

            +--rw user* [name]
               +--rw name        string
               +--rw password?   ianach:crypt-hash
               +--rw authorized-key* [name]
                  +--rw name         string
                  +--rw algorithm    string
                  +--rw key-data     binary

In ietf-ssh-server@2019-11-20:

       |  +-- supported-authentication-methods

       |  |  +-- publickey?   empty

       |  |  +-- passsword?   empty

       |  |  +-- hostbased?   empty

       |  |  +-- none?        empty

       |  |  +-- other*       string

       |  +-- users {client-auth-config-supported}?

       |  |  +-- user* [name]

       |  |     +-- name?        string

       |  |     +-- password?    ianach:crypt-hash

       |  |     +-- host-keys!

       |  |        +---u ts:local-or-truststore-host-keys-grouping

Maybe this latter better serves hostbased key authentication? Was that really the intention? Should it be possible to select between user authorized key and host based auth? So for example, if one selects publickey, then should it still configure a trusted host key?

The intention was to support "publickey" based auth (not "hostbased").  As I was telling Martin, it's the same key format, but it's called "hostkey" for servers and has no special name for clients.  I was being overzealous with naming it "hostkey" here.

That said, there should be a way to configure authenticating clients for *all* the methods, including "hostbased", which isn't supported in the model yet...

Could provide a diff that irons out these issues?

Thanks,
Kent