Re: [netconf] update to ssh-server draft

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

Hi Kent,

See below.
Br,
Balazs

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


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:



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.

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?

Balazs> Yes, I agree.

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

Balazs> Yes, please remove ‘other’.

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

Balazs> Ok, but then I assume the model/format of configuration should be the same as in RFC7317, 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.

Balazs> Ok.


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.

Balazs> I agree to both.

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.

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


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

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.

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