Subject: Re: [netconf] update to ssh-server draft

From: Balázs Kovács <[email-masked]>
Date: Sun, 12 Jan 2020 13:34:10 +0000

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 <[email-masked]>
Sent: Friday, November 22, 2019 4:49 PM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]
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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Jan 2020 22:30:27 +0000

Hi Balazs,

It is good to see that you're digging into the SSH modules, as they (and the NETCONF modules) are the only modules that I don't have running code for...

Regarding your questions:

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

RE "none": this is defined because it is in RFC 4252.  Yes, there's lots of guidance in that RFC regarding the use of "none", but it is *supported*...   I think what is needed here is a `feature` statement enabling the server to express if "none" is supported of not - agreed?

RE "other": I don't remember how "other" came to be listed, but it doesn't appear in RFC 4252 and therefore should be removed  (updated in my local copy).

> ‘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?

System-level and NETCONF-level users may not be the same.  I know some system co-mingle the two while others don't.

BTW, RFC 4252 says that "password" SHOULD be required, so a `feature` statement seem warranted.  RFC 4252 says that "publickey" is REQUIRED, so *no* `feature` statement is needed for it.

> 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).

RFC 4252 says that this method name is OPTIONAL, and therefore a `feature` statement seems warranted here as well.

Yes, it seems that ‘local-or-truststore-host-keys-grouping‘ would be in play here.

I don't think it needs to be under a username, as the SSH-client still explicitly sends a username (same as with "none") per RFC 4552 Section 5.

> 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?

Please check again, the tls-server-grouping does have 'client-auth-config-supported' (https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-17#section-4 <https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-17#section-4>).

Answering your last question, note that TLS-level client auth is optional, as client auth MAY occur at a protocol-layer above TLS.  That said, I'll grant you that this feature may not be ideal as instead, perhaps, the server could instead rely on *if* any of the descendants were configured.

I'm less sure about SSH, but I don't believe that client authentication can ever occur at a higher-level protocol layer.  That being the case, there's likely a good augment to removing the "client-auth-config-supported" feature in ietf-ssh-server.  

Kent // contributor

---

From: Balázs Kovács <[email-masked]>
Date: Wed, 22 Jan 2020 09:37:37 +0000

Hi Kent,

See below.
Br,
Balazs

From: Kent Watsen <[email-masked]>
Sent: Tuesday, January 14, 2020 11:30 PM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]
Subject: Re: update to ssh-server draft

Hi Balazs,

       |  |  +-- publickey?   empty

       |  |  +-- passsword?   empty

       |  |  +-- hostbased?   empty

       |  |  +-- none?        empty

       |  |  +-- other*       string

Balazs> Yes, I agree.

Balazs> Yes, please remove ‘other’.

Balazs> Ok, but then I assume the model/format of configuration should be the same as in RFC7317, right?

Balazs> Ok.

Balazs> I agree to both.

Balazs> You have to have a whitelist of users on the server side where you allow hostbased authentication. The rest of the users should not be able to login with a host key. We also need to somehow make it possible to stack authentication methods -> ask more than one for a login to succeed or whatever other policies are supported in general by an SSH server.

https://tools.ietf.org/html/rfc4252#section-4
https://man.openbsd.org/sshd_config#AuthenticationMethods

Please check again, the tls-server-grouping does have 'client-auth-config-supported' (https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-17#section-4).

Balazs> Ok, for TLS you are right, I accidentally missed that. I think in TLS it is ok as feature for the reasons you had. But in SSH case, I’ve only seen SSH doing the user authentication as of RFC 4252, as you said. So I’d vote for not having a feature for SSH client auth and that something must be configured there.

Balazs> I’m also thinking if certificate based authentication should be under the user whitelist, but I’m not very familiar with RFC6187.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Wed, 22 Jan 2020 17:48:14 +0000

Hi Balazs,

Please see commits from today: https://github.com/netconf-wg/ssh-client-server/commits/master <https://github.com/netconf-wg/ssh-client-server/commits/master>

As well some comments below.

Kent

> On Jan 22, 2020, at 4:37 AM, Balázs Kovács <[email-masked]> wrote:
> 
> Hi Kent,
>  
> See below.
> Br,
> Balazs
>  
> From: Kent Watsen <[email-masked] <mailto:[email-masked]>> 
> To: Balázs Kovács <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>

Feature added.

> Balazs> Yes, please remove ‘other’.

Removed.

> Balazs> Ok, but then I assume the model/format of configuration should be the same as in RFC7317, right?

I think the value typedef's to 'ssh-host-key’ in ietf-crypto-types.  If so, then good, right?

> BTW, RFC 4252 says that "password" SHOULD be required, so a `feature` statement seem warranted.  RFC 4252 says that "publickey" is REQUIRED, so *no* `feature` statement is needed for it.

Feature added.

> Yes, it seems that ‘local-or-truststore-host-keys-grouping‘ would be in play here.

Feature added.
Also added ‘use' of local-or-truststore-host-keys-grouping.

> https://tools.ietf.org/html/rfc4252#section-4 <https://tools.ietf.org/html/rfc4252#section-4>
> https://man.openbsd.org/sshd_config#AuthenticationMethods <https://man.openbsd.org/sshd_config#AuthenticationMethods>
I did not look into this.  For now this issue remains open.

> Balazs> Ok, for TLS you are right, I accidentally missed that. I think in TLS it is ok as feature for the reasons you had. But in SSH case, I’ve only seen SSH doing the user authentication as of RF…

I did not remove the "client-auth-config-supported” feature.  

I still believe that the reason stated in the feature's ‘description’ statement is valid.  Perhaps an alternative approach to this is to *remove* the ‘user’ list node altogether, forcing consuming applications to define their own strategy for how to authenticate ssh clients.  To the application, the difference is in if the client auth configuration is contained within the app’s equivalent concept of a “user”, or if the app maintains a leafref from its “user” to the 'client-authentication/user’ node for these values.  Does this make sense?

> Balazs> I’m also thinking if certificate based authentication should be under the user whitelist, but I’m not very familiar with RFC6187.

Could be, perhaps likely so.  If nothing else, it seems the most conservative thing to do.

Kent // contributor