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

From: Michal Vaško <[email-masked]>
Date: Fri, 02 Apr 2021 21:33:07 +0200

Hi Kent,

firstly I am sorry, somehow I missed this reply, my bad :(

> > I had a chance to look at these modules again and have 2 questions regarding some recent changes.
> > 
> > - ietf-ssh-server, ssh-server-grouping/client-authentication/supported-authentication-methods> 
> > Since the "other" leaf-list was removed there is no way to support some other methods than those specified. I am not sure whether this was the intention and if so, what is the reason for it? If nothing else, we support "interactive" authentication method but there are some others that I see no reason why they could not be used.
> 
> It took me a bit to determine that this change happened in ssh-client-server-18.
> 
> The motivation behind the change was to align the values with those defined in RFCs 4252 and 4250.
> 
> You mention an “interactive” and “some other” methods - where are they defined?

That is a good question. It seems no other methods are standardized but that does not mean they are not used.

> > For a robust and extendible solution, why not use an identityref leaf-list with all the methods as identities? One could then simply add new ones with specific "if-feature" statements.
> 
> An identityref seems reasonable, could you propose a snippet of YANG for it?
> 
> That said, it seems equally possible for a future module to augment-in a new leaf under the "supported-authentication-methods” container...

Right, that would solve the problem, too. So you can keep it the way it is, up to you which solution you prefer. Not sure why I did not think of augments first but identityrefs. But identityrefs are much more general so the implementation should probably depend on whether these authentication methods are to be used only for this single purpose or not.

> > - ietf-netconf-server, grouping netconf-server-grouping/client-identity-mappings
> > 
> > The "if-feature" on this container is strange. The practical problem is that if one wants to support certificates only for TLS, both one of the TLS features and "ssh-x509-certs" must be enabled. This then results in the container being defined for both SSH and TLS so there is no way to support it only for TLS or SSH.
> 
> Yes, granular features would be nice.  This issue is tracked here: https://github.com/netmod-wg/yang-next/issues/82 <https://github.com/netmod-wg/yang-next/issues/82>.  A possible fix would be to enable features on a per-XPath basis, perhaps using the “node-tags” draft going on in NETMOD.   Do you have a proposal?
> 
> BTW, shouldn’t the “if-feature” statement have an “or” (not an “and”) between the two major expressions?

Yes, I think "or" fits much better. I just was not sure whether there is not a specific reason why "and" was chosen.

Regards,
Michal

---

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Apr 2021 20:02:31 +0000

Hi Michal,

> firstly I am sorry, somehow I missed this reply, my bad :(

No worries!  :)

> That is a good question. It seems no other methods are standardized but that does not mean they are not used.

What change are you hoping to see?  Is there anyway that such changes could be augmented in, or must they be in the base module?

> Right, that would solve the problem, too. So you can keep it the way it is, up to you which solution you prefer. Not sure why I did not think of augments first but identityrefs. But identityrefs ar…

Either way is fine with me.  As the module is in WGLC currently, it would be good if others could express an option...

> Yes, I think "or" fits much better. I just was not sure whether there is not a specific reason why "and" was chosen.

OLD:        "(tls-listen or tls-call-home) and (sshcmn:ssh-x509-certs)”;
NEW:        "tls-listen or tls-call-home or sshcmn:ssh-x509-certs";

But what about your original question, are you okay with consuming modules augmenting-in use-specific if-feature statements? 

K.

---

From: Michal Vaško <[email-masked]>
Date: Mon, 05 Apr 2021 16:07:15 +0200

Hi Kent,

> What change are you hoping to see?  Is there anyway that such changes could be augmented in, or must they be in the base module?

Okay, so properly looking at all this, the 2 missing authentication methods (that are supported by libssh or sshd, or example) are actually standardized so I suppose you can add them directly into the YANG module. There are "keyboard-interactive" [1] (not "interactive") and "gssapi-with-mic" [2].

[1] https://tools.ietf.org/html/rfc4256
[2] https://tools.ietf.org/html/rfc4462

> NEW:        "tls-listen or tls-call-home or sshcmn:ssh-x509-certs";

Well, this is no good either because now ANY of those features are enabled, the certificates will be supported for BOTH TLS and SSH. What should be possible to support is X509 certificates for SSH, TLS, or both. That would require some more remodeling of "netconf-server-grouping", not just an "if-feature" update.

Regards,
Michal

---

From: Kent Watsen <[email-masked]>
Date: Mon, 19 Apr 2021 17:48:01 +0000

Hi Michal,

Please find responses below.

K.

> [1] https://tools.ietf.org/html/rfc4256 <https://tools.ietf.org/html/rfc4256>
> [2] https://tools.ietf.org/html/rfc4462 <https://tools.ietf.org/html/rfc4462>

Thanks for tracking those RFCs down.

From RFC 4256, the "keyboard-interactive” auth method was added here: https://github.com/netconf-wg/ssh-client-server/commit/6cc6a9ecd0be7db01c6a1ba39ed7b32ac6310163.

From RFC 4462, the "gssapi-with-mic” and “gssapi-keyex” auth methods were added here: https://github.com/netconf-wg/ssh-client-server/commit/ea518a6d7accc1cda656a5d1bc1300abf1c62f5a

It would be great if you could verify these additions.  I’m not myself configuring any SSH clients or servers, and thus the configuration-formulations are purely academic based on my reading of the RFCs.

Additionally, in ietf-ssh-server, the whole "client-authentication” container, especially its "supported-authentication-methods” and “users” descendent nodes, seem less than ideal.  Have you been using these trees, do them seem to be formulated correctly?

>> Either way is fine with me.  As the module is in WGLC currently, it would be good if others could express an option...

Anyone?

> Well, this is no good either because now ANY of those features are enabled, the certificates will be supported for BOTH TLS and SSH. What should be possible to support is X509 certificates for SSH,…

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.

My OLD/NEW update is trying to correct a logic error.  I believe the new formulation is correct.  It could be expanded to;

	(tls-listen or tls-call-home)
	or 
	( (ssh-listen or ssh-call-home) and sshcmn:ssh-x509-certs)

But I don’t think "(ssh-listen or ssh-call-home)” is needed, as certainly one would be true when "sshcmn:ssh-x509-certs” is enabled, right?

K.

---

From: Michal Vaško <[email-masked]>
Date: Tue, 20 Apr 2021 07:48:33 +0200

Hi Kent,

responses also inline.

> It would be great if you could verify these additions.  I’m not myself configuring any SSH clients or servers, and thus the configuration-formulations are purely academic based on my reading of the…

I am using only the "keyboard-interactive"  method and only as a user, so I do not have in-depth knowledge. However, it seems fine and should be now configurable, thanks! Like I said, I cannot say much about the "gssapi" methods, never used them. But they also seems fine to me.

> Additionally, in ietf-ssh-server, the whole "client-authentication” container, especially its "supported-authentication-methods” and “users” descendent nodes, seem less than ideal.  Have you been u…

We are not using them (yet) as the last draft we implemented was still missing some features. Looking at it now, it seems okay. 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.

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

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?

> But I don’t think "(ssh-listen or ssh-call-home)” is needed, as certainly one would be true when "sshcmn:ssh-x509-certs” is enabled, right?

Yes, I agree with this.

Regards,
Michal

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Apr 2021 00:57:40 +0000

Hiya Michal,

Please see below…

K.

And this response:

> We are not using them (yet) as the last draft we implemented was still missing some features. Looking at it now, it seems okay.

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

FWIW, my guess is that there’s at least a month until the netconf-client-server and restconf-client-server drafts complete their WGLCs, assuming they get kicked off in the next week or two as expected, and then we will quickly reach the point where it will be too late for anymore easy “do-overs”.

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

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

K.

---

From: Michal Vaško <[email-masked]>
Date: Wed, 21 Apr 2021 08:34:54 +0200

Hi Kent,

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

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.

> 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 el…

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?

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.

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

Regards,
Michal
153,154d152
<       if-feature
<         "(tls-listen or tls-call-home) and (sshcmn:ssh-x509-certs)";
217c215,217
<             uses ncs:netconf-server-grouping;
---
>             uses ncs:netconf-server-grouping {
>               if-feature "sshcmn:ssh-x509-certs";
>             }
312c312,314
<             uses ncs:netconf-server-grouping;
---
>             uses ncs:netconf-server-grouping {
>               if-feature "sshcmn:ssh-x509-certs";
>             }

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Apr 2021 22:09:06 +0000

Hi Michal,

> 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 sever…

Noted.

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

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,…

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

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

---

From: Michal Vaško <[email-masked]>
Date: Thu, 22 Apr 2021 09:10:36 +0200

Hi Kent,

> 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 cont…

I suppose I was not clear enough, the seeming redundancy is in all the specific client-authentication features AND the "supported-authentication-methods". You must both enable a feature and create the corresponding leaf/container to actually support the method.

But it seems enabled feature marks something like a capability of the system to support the authentication method and the data whether you actually want to advertise the method for new SSH clients. I am not sure this distinction is needed, though. It seems to me the "supported-authentication-methods" container can be removed altogether and the advertised authentication methods will simply be all the configured ones for the user.

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

I am sorry, I have still not adjusted to the fact that the modules now include all the configuration needed, with nothing being read from the system. Having understood this, I think the current principle of per-user configuration is fine, there is no other solution.

But to fully configure the "keyboard-interactive" method, there is some more information needed. I have looked at how libssh and OpenSSH sshd(7) configure this method.

Starting with sshd, it relies on login or PAM [1]. I do not have any experience with PAM so I do not know how exactly that is supported in these YANG modules. But as for login, it seems to basically duplicate the functionality of the "password" authentication [2]. That is my experience as well but I do not know any more background for this. So, the configuration would again be simply a "password" leaf.

As for libssh, it went for a completely generic solution in which you must specify the method name (which maps to the "submethod" would be my guess), the instruction, and a list of challenge-response prompts [3]. We have implemented the simple password authentication this way [4], when the password is read from the system (the login functionality, actually). Going with this full configuration, the instruction and a list of challenge-response prompts (with echo configuration) should be added to "{grouping:ssh-server-grouping}/client-authentication/users/keyboard-interactive/submethod”. Actually, why is "keyboard-interactive" a list? A container should be fine and "submethods" should probably be a list instead.

That is all the feedback I can provide for the "keyboard-authentication" method. I could even suggest the exact YANG changes if needed but I am missing the information about PAM support, if nothing else. Someone else could add something in case I missed anything and it would be great if you could find someone actually using the "gssapi" methods to provide similar feedback, otherwise you will likely have to rely on additional modules adding some augments, which is not an ideal solution.

[1] https://linux.die.net/man/5/sshd_config (search for ChallengeResponseAuthentication)
[2] https://www.freebsd.org/cgi/man.cgi?login.conf(5)#end (section AUTHENTICATION)
[3] https://api.libssh.org/stable/group__libssh__server.html (function ssh_message_auth_interactive_request)
[4] https://github.com/CESNET/libnetconf2/blob/master/src/session_server_ssh.c#L809

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

Um, I do not think that works. It took me a while to understand but based on the comment, you tried to add the "sshcmn:ssh-x509-certs" if-feature to the "client-identity-mappings" container. To my knowledge, what you actually did was augment-in no new nodes to the "client-identity-mappings" container, but making 'all these no nodes' conditional on an if-feature, none of which makes sense. The "if-feature" in an augment relates to the "augment" itself, not to its target, you can only add new nodes with an augment.

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

I have never configured or used certificates for SSH authentication so this is not a question that I can answer. But based on my other experience, I would naively guess that it means you are using certificates instead of SSH keys, which seems to me is relevant for the "hostbased" and "publickey" authentication methods and would, in-effect, replace the configuration of these methods. But that is not what is found in these YANG modules so I guess I am wrong.

Regards,
Michal

---

From: Kent Watsen <[email-masked]>
Date: Thu, 22 Apr 2021 19:21:09 +0000

Hi Michal,

> But it seems enabled feature marks something like a capability of the system to support the authentication method and the data whether you actually want to advertise the method for new SSH clients.  I am not sure this distinction is needed, though.

The “feature” indicates if the server supports that configuration at all.  For instance, there may be an SSH server that only supports “publickey" or only X509 certs.  The feature gates what can be configured, long before a handshake.

> It seems to me the "supported-authentication-methods" container can be removed altogether and the advertised authentication methods will simply be all the configured ones for the user.

The "supported-authentication-methods” are to know what list of auth-methods to present to the SSH client during the handshake.  It would be ideal if this list could be derived from either “features” and as the union of the methods configured for each user.

Looking at RFC 4252, Section 5.1 (Responses to Authentication Requests) says:

   If the server rejects the authentication request, it MUST respond
   with the following:

      byte         SSH_MSG_USERAUTH_FAILURE
      name-list    authentications that can continue
      boolean      partial success

   The 'authentications that can continue' is a comma-separated name-
   list of authentication 'method name' values that may productively
   continue the authentication dialog.

   It is RECOMMENDED that servers only include those 'method name'
   values in the name-list that are actually useful.  However, it is not
   illegal to include 'method name' values that cannot be used to
   authenticate the user.

   Already successfully completed authentications SHOULD NOT be included
   in the name-list, unless they should be performed again for some

And Section 5.2 (The "none" Authentication Request) says:

   A client may request a list of authentication 'method name' values
   that may continue by using the "none" authentication 'method name'.

   If no authentication is needed for the user, the server MUST return
   SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return
   SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of methods
   that may continue in its 'authentications that can continue' value.

So my reading is that the list of auth methods SHOULD be user-specific but MAY be (dare I say) feature-specific.  In either case, it seems that an explicit "supported-authentication-methods” may be too much.  I’m tempted to remove it...

> I am sorry, I have still not adjusted to the fact that the modules now include all the configuration needed, with nothing being read from the system. Having understood this, I think the current pri…

I’m unsure if “nothing being read from the system” is accurate.  Yes, this has been a thought, but I think it falls into two broad categories:

1) per-user credentials (e.g., passwords in /client-authentication/users) 
2) user-independent credential authenticators
      2a) configured PKI issuers (e.g., “ee-certs” and “ca-certs”)
      2b) configured callout mechanisms (e.g., PAM, LDAP, Radius, etc.)

Some comments:

  - we do not yet have anything in the model representing (2b)
  - (1) could always be viewed as something that should be provided by a (2b)

> As for libssh, it went for a completely generic solution in which you must specify the method name (which maps to the "submethod" would be my guess), the instruction, and a list of challenge-response prompts [3]. We have implemented the simple password authentication this way [4], when the password is read from the system (the login functionality, actually). Going with this full configuration, the instruction and a list of challenge-response prompts (with echo configuration) should be added to "{grouping:ssh-server-grouping}/client-authentication/users/keyboard-interactive/submethod”.

I very much agree with modeling after how other well-known servers are configured.  One thing for sure, per-user passwords, public keys, and the like are NOT configured in sshd_config (they’re in a per-user directory, accessible via PAM, presumably).

Per auth method:

  - hostbased:
      - specifies all config via:
          - HostKey, HostKeyAlgorithms, and HostbasedAuthentication

  - password:
      - config just flags: PasswordAuthentication., PermitEmptyPasswords
      - but /etc/passwd typically used

  - publickey:
      - in sshd_config, a callout can be configured via AuthorizedKeysCommand
      - ...but ~/.ssh/authorized_keys typically used

  - keyboard-interactive
      - config just the flag KbdInteractiveAuthentication

  - gssapi
      - config just the flag GSSAPIAuthentication
      - apparently internally calls out to Kerboros on some systems

  - kerboros?
          - KerberosAuthentication

> Actually, why is "keyboard-interactive" a list? A container should be fine and "submethods" should probably be a list instead.

Perhaps, but I was thinking that by it being a list, augments could vary by submethod.  I dunno how important that might be hough..

> That is all the feedback I can provide for the "keyboard-authentication" method. I could even suggest the exact YANG changes if needed but I am missing the information about PAM support, if nothing…

Any suggestions you have would be good.  

Honestly, I’m wondering if we should zero-out the "client-authentication’ and thereby force any consuming application to augment-in whatever config it thinks is needed…thoughts about that?

> Um, I do not think that works. It took me a while to understand but based on the comment, you tried to add the "sshcmn:ssh-x509-certs" if-feature to the "client-identity-mappings" container. To my…

Oh bother, the whole “augment” vs. “refine” mixup again, here’s the fix:

https://github.com/netconf-wg/netconf-client-server/commit/f81d0c5b0a3361a4903b87c9777c33b1d143975c

> I have never configured or used certificates for SSH authentication so this is not a question that I can answer. But based on my other experience, I would naively guess that it means you are using…

X.509-based auth *is* a variation of “publickey” auth, so a “username” is still being passed in the SSH_MSG_USERAUTH_REQUEST message...

K.

---

From: Michal Vaško <[email-masked]>
Date: Fri, 23 Apr 2021 09:02:14 +0200

Hi Kent,

> So my reading is that the list of auth methods SHOULD be user-specific but MAY be (dare I say) feature-specific.  In either case, it seems that an explicit "supported-authentication-methods” may be…

Right, that is what I suggested, too. Based on the references it seems returning user-specific supported-authentication list is the best thing to do, anyway.

>   - (1) could always be viewed as something that should be provided by a (2b)

Thanks for the information, good to know.
 
>       - apparently internally calls out to Kerboros on some systems

One can always rely on the system itself if the feature "client-auth-config-supported" is kept disabled. But if enabled, all the information needed to configure an authentication method should be in the YANG module, right? It seems to me that is how it is now, for all the previous methods, I tried to suggest what can be done for the "keyboard-interactive" method to be like that, too.

> Honestly, I’m wondering if we should zero-out the "client-authentication’ and thereby force any consuming application to augment-in whatever config it thinks is needed…thoughts about that?

I think that could easily prevent interoperability and see no reason for that. You got this far, would be a shame to give up now :) I have attached my changes that should allow to configure any "keyboard-interactive" authentication. The information should all be there but the descriptions may be too brief.

> https://github.com/netconf-wg/netconf-client-server/commit/f81d0c5b0a3361a4903b87c9777c33b1d143975c

Seems okay now.

> X.509-based auth *is* a variation of “publickey” auth, so a “username” is still being passed in the SSH_MSG_USERAUTH_REQUEST message...

Right, it takes me some time to absorb all the implications. So what exactly is the purpose of "client-identity-mappings" for SSH? A client must always present its username when authenticating using SSH and it can be chosen so I do not see the point of changing the NETCONF session username based on the presented certificate and the cert-to-name mapping configuration. Am I missing something?

Actually, maybe I can think of a scenario. Supposing there are some NETCONF clients deployed that use SSH for authentication but want to identify users based on their certificates. Then there could be a single username always used for SSH authentication but the NETCONF client would map the specific certificate to a NETCONF username. That would allow the server, for example, to still implement NACM but effectively identify users only based on their certificates.

In this case your original question makes sense to me and I would see 2 solutions. Either there would have to be the expected SSH username configured in order for all the associated cert-to-name mappings to take effect or simply all the configured mappings would always be tried and if some is successful, the resolved username will always be used for NETCONF. I suppose a combination of this is also possible when the expected SSH username may or may not be configured.

Regards,
Michal
438c438
<           list keyboard-interactive {
---
>           container keyboard-interactive {
440c440,441
<             key submethod;
---
>             presence
>               "Indicates that the 'keyboard-interactive' method is supported.";
442,447c443,449
<               "Indicates that the server can authenticate this
<                user using the configured submethod.  Consuming
<                modules may augment-in submethod-specific
<                configuration as needed.";
<             leaf submethod {
<               type string;
---
>               "A set of presented challenge-expected response pairs
>                may be used by the SSH server to authenticate this user.";
>             leaf default-submethod {
>               mandatory true;
>               type leafref {
>                 path "submethod/name";
>               }
449c451,458
<                 "The name of the 'submethod'.  Valid values are
---
>                 "If the user does not request any specific
>                  submethod, this one will be used.";
>             }
>             list submethod {
>               key "name";
>               min-elements 1;
>               description
>                 "All the submethods supported for the user. Valid values are
451a461,497
>               leaf name {
>                 type string;
>                 description
>                   "Submethod name.";
>               }
>               leaf instruction {
>                 type string;
>                 description
>                   "The instruction presented to the user for this
>                    submethod.";
>               }
>               list prompt {
>                 key "challenge";
>                 min-elements 1;
>                 description
>                   "List of prompts presented to the user that
>                    must be passed for successful authentication
>                    of this submethod.";
>                 leaf challenge {
>                   type string;
>                   description
>                     "The challenge (prompt) presented to the user.";
>                 }
>                 leaf response {
>                   mandatory true;
>                   type string;
>                   description
>                     "The expected response to the challenge.";
>                 }
>                 leaf echo {
>                   type boolean;
>                   default true;
>                   description
>                     "Whether to enable or disable shell echo in case
>                      some sensitive information is requested.";
>                 }
>               }

---

From: Michal Vaško <[email-masked]>
Date: Fri, 23 Apr 2021 09:32:48 +0200

Second time I forgot so I'd rather send it now so that I do not forget again. It seems to me that "{grouping:ssh-server-grouping}/client-authentication" contains really sensitive information so I would expect it to have "nacm:default-deny-all;".

> >    The 'authentications that can continue' is a comma-separated name->    list of authentication 'method name' values that may productively
> >    A client may request a list of authentication 'method name' values>    that may continue by using the "none" authentication 'method name'.
> > 
> >    SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return>    SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of methods

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Apr 2021 22:32:49 +0000

Hi Michal,

Thinning out resolved items below.

Thanks,
Kent

> One can always rely on the system itself if the feature "client-auth-config-supported" is kept disabled.

True.

> But if enabled, all the information needed to configure an authentication method should be in the YANG module, right?

Yes.

> It seems to me that is how it is now, for all the previous methods, I tried to suggest what can be done for the "keyboard-interactive" method to be like that, too.

Okay, thanks.

> I think that could easily prevent interoperability and see no reason for that. You got this far, would be a shame to give up now :)

Okay.

> I have attached my changes that should allow to configure any "keyboard-interactive" authentication. The information should all be there but the descriptions may be too brief.

I’ve incorporated the changes here: https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0.

Note that this commit also removed the "supported-authentication-methods” container.

Questions:
  1) would you like you be added as a “Contributor”?
  2) should either “instruction” or “challenge” nodes be mandatory?
  3) should “ee-certs”/“ca-certs” be moved under the “user” node too?
  4) is there a need to provide a similar “keyboard-interactive” update for the ssh-client?

On #3, this is likely mostly for me to resolve, but it seems to me that *all* client-auth details should be under the “user” node.  Yes, a bag-of-certs (or a single CA cert) could be used to auth a multiplicity of users, but having that reference configured per user (perhaps redundantly) is 1) more consistent and 2) better supports the server being able to produce a list of “productive method names” to return to the client.  Thoughts?

Separately, for background, I mentioned before that X.509-cert auth is a variation of the “publickey” authentication method.  RFC 4253, Section 6.6 clearly indicates this, as it consistently says "certificate or public key”, and RFC 6187, Section-2.1 likewise supports this.  So, we could push the whole “how to support X.509 formatted keys” into/under the “publickey” umbrella.   That said, it is way more natural for administrators to configure certs in their normal form then in the ssh-publickey form, hence why the ssh-client and ssh-server models have them broken out as they are.

> In this case your original question makes sense to me and I would see 2 solutions. Either there would have to be the expected SSH username configured in order for all the associated cert-to-name ma…

Digging into RFC 6187 again, I find this jewel:

   For the purposes of user authentication, the mapping between
   certificates and user names is left as an implementation and
   configuration issue for implementers and system administrators.

This is wild as is simultaneously suggests that a mapping (i.e. x509c2n:cert-to-name) may be needed while ignoring the fact that the “user name” is already being passed in the base SSH_MSG_USERAUTH_REQUEST message.

Popping this discussion back up to YANG models, ietf-netconf-server current has this snippet:

          container netconf-server-parameters {
            description
              "A wrapper around the NETCONF server parameters
               to avoid name collisions.";
            uses ncs:netconf-server-grouping {
              refine "client-identity-mappings" {
                if-feature "sshcmn:ssh-x509-certs";
                description
                  "Augments in an 'if-feature' statement
                   ensuring the 'client-identity-mappings'
                   descendent is enabled only when SSH
                   supports X.509 certificates.";
              } // FIXME: does an X.509-derived identity
            }   //        override SSH username?
          }

The questions are:

  1) are "client-identity-mappings” needed at all?
  2) if “yes”, then do they override the base “user name” value?

For #1, I think you’re saying that flexibility is good and, for #2, RFC 6187 seems to be saying that it’s a matter of local policy.  Agreed?

K.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 23 Apr 2021 22:36:43 +0000

Hi Michal,

> Second time I forgot so I'd rather send it now so that I do not forget again. It seems to me that "{grouping:ssh-server-grouping}/client-authentication" contains really sensitive information so I would expect it to have "nacm:default-deny-all;”.

It’s already “default-deny-write”.  I only use “default-deny-all” (to also prevent reads) for cleartext passwords and private-keys.  I’ll leave it is for now, pending more discussion.

K.

---

From: Michal Vaško <[email-masked]>
Date: Mon, 26 Apr 2021 08:30:55 +0200

Hi Kent, 

> Note that this commit also removed the "supported-authentication-methods” container.

Great, thanks. Connected to the separate NACM-related question, the most common way of configuring the keyboard-interactive authentication is to request the user password, which would have to be stored in clear-text now. To cover it, you could replace the "response" leaf by a choice with "answer" string leaf and "password" ianach:crypt-hash leaf, for example. And leave some other possible specific responses for augments.

>   1) would you like you be added as a “Contributor”?

That is up to you, I am fine either way.

>   2) should either “instruction” or “challenge” nodes be mandatory?

As for "instruction", I left it optional on purpose because it should not be required for correct functioning of this authentication method. But I do think it should be configured so it is up to you to decide. Regarding "challenge", what do you mean? It is the key of a list so it is mandatory.

>   4) is there a need to provide a similar “keyboard-interactive” update for the ssh-client?

To be honest, I did not look at this module previously because our CLI NETCONF client implementation is rather simple so we did not bother using this YANG module at all. But looking at it now, it seems to me it is the way I would expect it to be, all this new configuration is server-side only.

But, our NETCONF library does provide some additional configuration of the client SSH authentication so I will mention it and leave for you whether you want to add it into the modules or not. We support customizing the priority of each method so that there are no 'wasted' methods that only increase the authentication attempts. It seems that this is prevented in the SSH client module by all the "if-feature" on the individual methods, so that the unsupported ones can be disabled. But I think it may be useful for the client to be able to configure its preferred methods, in order, because you probably do not want to be bothered with the "password" authentication when you have a public key configured, for instance.

> Separately, for background, I mentioned before that X.509-cert auth is a variation of the “publickey” authentication method.  RFC 4253, Section 6.6 clearly indicates this, as it consistently says "…

But you do need to configure the public key for the user if you want to authenticate it by a certificate, right? Assuming so, I think it is fine the way it is but I do agree with your points and see no problems with the change you proposed, either way seems fine.

> For #1, I think you’re saying that flexibility is good and, for #2, RFC 6187 seems to be saying that it’s a matter of local policy.  Agreed?

For #1 I came up with a possible scenario when the "client-identity-mappings" could possibly have their use. If the scenario is unlikely to be used in practice or simply not relevant for some reason and you (or anyone else) are not able to come up with any other, I think these mappings are not needed. Just a note, we do not and not plan to support the scenario.

As for #2, I think I have suggested a way to allow configuring it either way so that the 'local policy' can be directly configured. And that would probably be the best solution.

Regards,
Michal

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Apr 2021 17:06:48 +0000

Hi Michal,

> Great, thanks. Connected to the separate NACM-related question, the most common way of configuring the keyboard-interactive authentication is to request the user password, which would have to be st…

I don’t doubt you, but already SSH (* see below) allows for a multiplicity of authentication methods so, e.g., “publickey password keyboard-interactive” would mean that the client must first pass “publickey”, then “password”, and finally “keyboard-interactive”.  My point is that, if a password is to be asked for, wouldn’t the “password” method be preferably used, and hence the existing "ianach:crypt-hash” protection suffice?  

That said, I’m not against converting the “leaf” to a “choice with a single ‘cleartext’ leaf” case if you think it’s better...

* The sshd_config manage says:

    AuthenticationMethods
             Specifies the authentication methods that must be successfully completed for a user to be granted access.  This
             option must be followed by one or more lists of comma-separated authentication method names, or by the single
             string any to indicate the default behaviour of accepting any single authentication method.  If the default is
             overridden, then successful authentication requires completion of every method in at least one of these lists.

             For example, "publickey,password publickey,keyboard-interactive" would require the user to complete public key
             authentication, followed by either password or keyboard interactive authentication.  Only methods that are next in
             one or more lists are offered at each stage, so for this example it would not be possible to attempt password or
             keyboard-interactive authentication before public key.

As yet, with the current model, I don’t see a direct correlation to “AuthenticationMethods”, unless you think “keyboard-interactive” is it, but that doesn’t follow from the manpage snippet above.

> That is up to you, I am fine either way.

Added.

> To be honest, I did not look at this module previously because our CLI NETCONF client implementation is rather simple so we did not bother using this YANG module at all. But looking at it now, it s…

In ietf.-ssh-client: should "leaf-list submethods” or "leaf-list oids” be ordered-by user?

RELATED:  In iets-ssh-server: should any of “list submethod, “list prompt”, or "list gssapi-with-mic” be ordered-by user?

> But, our NETCONF library does provide some additional configuration of the client SSH authentication so I will mention it and leave for you whether you want to add it into the modules or not. We su…

The ssh_config manage has:

     PreferredAuthentications
             Specifies the order in which the client should try authentication methods.  This allows a client to prefer one
             method (e.g. keyboard-interactive) over another method (e.g. password).  The default is:

                   gssapi-with-mic,hostbased,publickey,
                   keyboard-interactive,password

We could support this either by:

1) wrap everything inside an “ordered-by user” list

2) define a “PreferredAuthentications” like variable, to provide an external ordering

Thoughts?

> But you do need to configure the public key for the user if you want to authenticate it by a certificate, right? Assuming so, I think it is fine the way it is but I do agree with your points and se…

If in your first question you mean an “X.509-based publickey”, then yes, but...

- if auth happens via an "ee-cert”, the ee-cert for each user needs to be configured, but it’s open as to if each user points to a specific ee-cert or if all users point to a bag of ee-certs.

- if auth happens via “ca-cert”, the same statements apply, but there is even less affinity, as typically a CA issues many EEs.

> For #1 I came up with a possible scenario when the "client-identity-mappings" could possibly have their use. If the scenario is unlikely to be used in practice or simply not relevant for some reaso…

Ack, and we shouldn't support a low-probability use-case.

> As for #2, I think I have suggested a way to allow configuring it either way so that the 'local policy' can be directly configured. And that would probably be the best solution.

I think what you are saying is:

1) if a cert-to-name mapping is NOT found, then fallback to the SSH-level username

2) if a cert-to-name mapping IS found, then it SHOULD override the SSH-level username.

Correct?

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Apr 2021 19:21:43 +0200

> As yet, with the current model, I don’t see a direct correlation to “AuthenticationMethods”, unless you think “keyboard-interactive” is it, but that doesn’t follow from the manpage snippet above.

SSH iterates over the authentication methods that both peers
offer. The 'keyboard-interactive' method (RFC 4256) hooks into PAM,
for many setups this results by default to password authentication,
but depending on the PAM module selected, 'keyboard-interactive' can
carry more complex challenge response dialogues.

   [...] With the generic
   method defined here, clients will not require code changes to support
   new authentication mechanisms, and if a separate authentication layer
   is used, such as [PAM], then the server may not need any code changes
   either.

>From a YANG perspective, keyboard-interactive is of course challenging
to model since you end up modeling something as flexible as PAM...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Michal Vaško <[email-masked]>
Date: Tue, 27 Apr 2021 08:54:00 +0200

Hi Kent, 

> In ietf.-ssh-client: should "leaf-list submethods” or "leaf-list oids” be ordered-by user?

Right, yes, I believe so.

> RELATED:  In iets-ssh-server: should any of “list submethod, “list prompt”, or "list gssapi-with-mic” be ordered-by user?

Reading through the RFCs again, I think all of these lists should actually be user-ordered, I missed that before. Moreover, if "list submethod" is user-ordered, the default submethod should simply be the first one and you can remove the "leaf default-submethod".

> 2) define a “PreferredAuthentications” like variable, to provide an external ordering

This is probably just a YANG modeling issue. I was already thinking about 1) and it seems to me it would make for a nice configuration data, but the YANG itself would be cluttered. Nevertheless, there may be a clean solution I am missing so it is up to you. We have simply assigned a priority to each authentication method, but I am not saying that is ideal.

> - if auth happens via “ca-cert”, the same statements apply, but there is even less affinity, as typically a CA issues many EEs.

Yes, I understand, but I have too little experience with certificates and practical use-cases so I am not able to decide whether the certificate configuration can be only per-server or needs to be per-user.

> 2) if a cert-to-name mapping IS found, then it SHOULD override the SSH-level username.

If you decide to keep this mappings, I was suggesting a completely generic solution when you could configure a specific username for the cert-to-name mappings.

1) If the user name is configured and
  a) matches the SSH user name, you try to use the mapping and override the SSH user name.
  b) does not match the SSH user name, you ignore this mapping.
2) If the user name is not configured, you always try to use the mapping.

But there is still the question of what to do if you find no matching mapping. I suppose it could be a separate configuration leaf deciding whether you want to fall back on the SSH user name or fail the authentication altogether.

Regards,
Michal

---

From: Michal Vaško <[email-masked]>
Date: Tue, 27 Apr 2021 08:58:42 +0200

Thanks for the input. So based on this my idea was simply to allow to configure this common use-case directly. But yes, it would result in configuring the password twice although once for the "password" authentication, the second time for the "keyboard-interactive" method. I consider that not to be a problem and believe the distinction between the used methods being important on its own.

Regards,
Michal

On Monday, April 26, 2021 19:21 CEST, Juergen Schoenwaelder <[email-masked]> wrote: 
 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Apr 2021 09:32:36 +0200

Well, my point is that keyboard-interactive may mean password
authentication but it may also mean other things. On a Unix system,
the traditional password can be seen as a property of an account,
i.e., not something that belongs to a specific authentication method.
In other words, if my keyboard-interactive (PAM) configuration is
setup to check the password of my account, then it checks the same
password that also the password authentication mechanism would check.
But with PAM, I can also make keyboard-interactive check something
else.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Apr 2021 14:24:41 +0000

Hi Juergen,

Are you saying that a client SHOULD use the “password” method for password-based authentication?  That is, from a modeling perspective, the “keyboard-interactive” method’s “response” node can remain a cleartext value, even though it MAY contain a password?    Note that, on most servers, the “password” method is a lookup into the local users database (e.g., /etc/passwd).

When using a password with keyboard-interactive, I expect that the password would be handled/compared via some PAM-like proxy.  As such, the password would NOT be statically-configured in the model (unlike with the “password” method), but rather in an external DB (/etc/passwd, RADIUS, LDAP, etc.).  Hence I question introducing a “choice” node to the “response” for iana:crypt-hash or encrypted values...

K.

> On Apr 27, 2021, at 3:32 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Apr 2021 17:55:44 +0200

> Are you saying that a client SHOULD use the “password” method for password-based authentication?  That is, from a modeling perspective, the “keyboard-interactive” method’s “response” node can remai…

On systems that support PAM, essentially all utilities that do user
authentication hook into the PAM mechanism and hence they can all be
configured to implement the security policy of choice. By default,
programs like login or sshd or ... typically end up calling the
tradtional Unix PAM module, that does a verification of a password
against a stored crypt-hash value. But this is only one of many
possible options. You can easily change the configuration to talk to a
RADIUS server instead or to a Kerberos 5 server or ... The PAM system
is very flexible. Note that it is possible to have PAM modules
(keyboard-interactive) where the server sends a challenge to the
client, the clients displays it to the user, collects the users
response, and forwards it back to the server and this exercise may be
repeated several times. Note that the server's PAM configuration
drives an interaction with the user via the keyboard until it is
either happy or not.

> When using a password with keyboard-interactive, I expect that the password would be handled/compared via some PAM-like proxy.  As such, the password would NOT be statically-configured in the model…

Yes, if you end up in the Unix PAM module, then keyboard-interactive
and password authentication become more or less the same. But this is
a special case from the keyboard-interactive (PAM) perspective,
despite the fact that it might be a common case. What exactly happens
when keyboard-interactive is executed is determined by the server's
PAM configuration and the client is expected to deal with it in an
interactive manner (i.e., not good for automation).

RFC 7317 likely got the tradeoffs right on the client side from what
you typically find as default setups on networking gear. Completely
modeling and exposing keyboard-interactive is likely something you
want to leave to an extension (for someone who has a lot of spare
cycles).

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Apr 2021 19:07:52 +0000

Hi Juergen,

I’m familiar with how PAM et. al. works.  The question in front of us is what the “server” models should look like, specially the SSH and HTTP server models, as they are the only two that have a “users” subtree.

The TLS model (just like the SSH and HTTP models) has a “client-authentication” subtree, but it’s wholly leafrefs into the truststore, and hence no “users” need to be locally defined.

All three models have a "client-auth-config-supported” feature (possibly better named 'client-auth-local-config”) that enables the “client-authentication” subtree.  This is in recognition that the models can go only so far, and it’s expected that application-specific augments may be needed.

In my view, the TLS "client-authentication” subtree is likely good for most production environments, whereas the SSH and HTTP subtrees are good for simple environments with small number of users.  For instance, the HTTP-subtree is most like an `htpasswd` database.  The SSH-subtree is intended to be equally simple...

[Michal: was/is your use simple?  Knowing that “keyboard-interactive” isn’t simple, my query is more in terms of the total number of users…]

K.

Disclaimer: I have no hands-on experience with either the SSH or HTTP "client-authentication” nodes.  My RESTCONF server implements the "restconf-server-app-grouping” and supports both TLS- and HTTP- level client auth, but it uses the "client-authentication” node only from the TLS model, as it was more intuitive to maintain a distinct “user” model than to define users in the “http-server-parameters” grouping inside the part of the data model for configuring the transport (ie., what addr/ports to listen on, etc.).

> On Apr 27, 2021, at 11:55 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Apr 2021 23:00:46 +0200

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?

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

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

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

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Apr 2021 22:45:21 +0000

Hi Juergen,

> 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

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. 

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

> vendors have prototyped extensions paving the way to a standard

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.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Apr 2021 01:51:01 +0000

Hi Michal,

> Right, yes, I believe so.

Fixed.

> Reading through the RFCs again, I think all of these lists should actually be user-ordered, I missed that before. Moreover, if "list submethod" is user-ordered, the default submethod should simply…

All done.  Now the description on "list submethod” says:

               "All the submethods supported for the user.
                If the user does not request any specific
                submethod, the first one will be used."

> This is probably just a YANG modeling issue. I was already thinking about 1) and it seems to me it would make for a nice configuration data, but the YANG itself would be cluttered. Nevertheless, th…

#1 seems better at first but, assuming the list is called “authentication-method”, the immediate issue is what the “key” should be.  We’d have to introduce a somewhat artificial “name” node, which makes the approach less appealing.

#2 seems easy enough:

   leaf-list preferred-authentications {
     type enumeration {
       enum publickey { ... }
       enum password { ... }
       enum hostbased { ... }
       ...
     }

But new “enums” cannot be augmented into an “enumeration” (in case that is ever desired).  We could use “type string”, but that's too open.  Another option would be to define a hierarchy of identities and then have a leaf-list of identityrefs.  This could work, but...

Now I’m thinking to leave the order unspecified, since it’s a minor optimization (saving a round-trip), as the “none” option can be used to get a “productive methods” list from the server.  

You said that you’d did this optimization before, but did it really matter, to save one roundtrip, especially in the context of using the keyboard-interactive method?

How about this for the the “client-identity” node’s description?

      "The credentials are unordered.  Clients may initially send
        any configured method or, per RFC 4252, Section 5.2, send
        the 'none' method to prompt the server to provide a list
        of productive methods."

> Yes, I understand, but I have too little experience with certificates and practical use-cases so I am not able to decide whether the certificate configuration can be only per-server or needs to be…

This is why I wrote before that it would likely be up to me to resolve  ;)

I think I’ll sleep on it, maybe insight will come in the morning...

> But there is still the question of what to do if you find no matching mapping. I suppose it could be a separate configuration leaf deciding whether you want to fall back on the SSH user name or fai…

Added that mappings override the SSH-level username.

Added a separate configuration leaf for if a mapping is *required*

K.

---

From: Michal Vaško <[email-masked]>
Date: Wed, 28 Apr 2021 07:53:52 +0200

Hi Kent,

starting with the issue of the exact purpose of all these modules, I may have misunderstood. It seemed to me they are meant to fully configure an SSH server/client, NETCONF server/client, ... With the limitation of leaving out some rare or too complex use-cases up to augments. At least that is what I was trying to help you with, but these criteria are subjective, of course.

Still, I think we are pretty close now, from my perspective. As was discussed, the "keyboard-interactive" method is a completely generic one where the user is presented with a set of challenges and must correctly respond to them to pass the authentication. That should already work and the issue I was trying to solve is a security one, when the expected response is some sensitive information. Adding that, I think the configuration would be able to (safely) express all configurations that do not require any additional information (such as, I don't know, retrieving the expected response from some remote server). Incidentally, the expected response of the user password would also be supported.

More below.

>         the 'none' method to prompt the server to provide a list

Like I said, the best example of a problem we were solving with these priorities was that when your SSH client has both "publickey" and "password" authentications supported and working and you connect to an SSH server that supports the "publickey" authentication, it is probably the method you prefer. I may be missing something but how do you solve this problem without some way of expressing these priorities explicitly? I do not see how getting the supported methods from the server will help you, it is strictly up to the client which of the methods it will select next (first).

> Added a separate configuration leaf for if a mapping is *required*

So you have decided to keep it? In any case, its functionality should now be unambiguous.

Regards,
Michal

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Apr 2021 09:11:16 +0200

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

I am not advocating anything. I just tried to clarify that
keyboard-interactive is a complex authentication mechanism to model
since you have to model some of the functionality of PAM for it.  If
you enable keyboard-interactive in your sshd config, you are
essentially saying "go and read the PAM configuration to figure out
what will happen".
 
> 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/c434d249baeab8f…

To me this makes little sense, you are not done by statically
configuring challenges and responses, this is from my view really
missing the point of keyboard interactive. I am sure you can write
a PAM module that does that but the value of keyboard is not this
kind of trivial configuration.

My point is that if we model keyboard-interactive, we have to get it
right, which is complex. Hence my suggestion is to not model it at this
point in time.

I also stumbled over

	"A list of locally configured users (i.e., SSH clients).";

For me, an SSH client and a locally configured user are very different
things. For me, the SSH client is the piece of code running on the
client side, the user is an account on the remote system.

> 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 m…

Well, you can configure SSH user authentication mechanism to reach out
to RADIUS or Kerberos or Diameter or ... RFC 7317 does support the
RADIUS backend option. Having to augment in new trees to support lets
say RADIUS is somewhat expensive. (I _assume_ you can call out to
RADIUS from the SSH password authentication method, i.e., this may not
require to have keyboard-interactive.) But perhaps also this can be
dealt with once there is more implementation experience.

/js

---

From: Michal Vaško <[email-masked]>
Date: Wed, 28 Apr 2021 09:23:09 +0200

Hi Juergen,
I tried to explain below that your understanding of the configuration meaning is wrong, let Kent correct me if it is me who got it wrong.

> essentially saying "go and read the PAM configuration to figure out

That is specific to sshd and is supported in the modules if you disable "client-auth-config-supported". But if you enable it, you want to configure the authentication yourself, in the module.

> kind of trivial configuration.

Reading the RFC that defines this method, I think it models it exactly the way it is defined. Please ignore PAM, it is not used if this configuration is in-effect.

> right, which is complex. Hence my suggestion is to not model it at this

It seems fairly straightforward, from its definition.

> client side, the user is an account on the remote system.

Again, the point of having "client-auth-config-supported" enabled is that you do not read the authentication information from the system and ignore any 'accounts on the remote system'. Instead, you configure the allowed users yourself.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Apr 2021 09:38:39 +0200

Let me quote from RFC 4256:

   [...] The major goal of this method is to
   allow the SSH client to support a whole class of authentication
   mechanism(s) without knowing the specifics of the actual
   authentication mechanism(s).

   [...] The major goal of this
   method is to allow the SSH client to have little or no knowledge of
   the specifics of the underlying authentication mechanism(s) used by
   the SSH server.  This will allow the server to arbitrarily select or
   change the underlying authentication mechanism(s) without having to
   update client code.

   The name for this authentication method is "keyboard-interactive".

If we model something as keyboard-interactive, it can't be a list of
static strings to justify that name.

My reading is that the SSH protocol talks about users. Whether these
users map to system level accounts (as they would do with a regular
sshd) or to some notion of 'virtual' users (on a system that shields
the system behind a NETCONF server) is I believe an implementation
choice.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Apr 2021 22:19:01 +0000

Hi Michal,

> starting with the issue of the exact purpose of all these modules, I may have misunderstood. It seemed to me they are meant to fully configure an SSH server/client, NETCONF server/client, ... With…

I’d say “fully configure, within reason.”

1) Easy: TCP and TLS

    These are easy because they don't ever entail interacting with user databases.

2) Moderate: SSH (password, publickey, hostbased, none) and HTTP (basic, digest)

    These are moderate because there’s a potential for callouts to remote user databases and, if so, then we don’t have the model to define how to do those callout yet.   However, a simple/built-in user-database is straightforward to configure.  [caveat: some SSH servers (e.g., sshd) enable a multiplicity of these mechanisms (e.g., first publickey, then password), which we don’t have an answer for yet.]

<aside> The “http" draft originally modeled a number of HTTP auth methods.  In an early review, the HTTPBIS working group beat-up that approach, so we backed-off to having an “auth-type” choice node with just a single “basic” case statement, thus enabling consuming models to augment-in any other auth mechanism config desired. </aside>

3) Not Easy: SSH and HTTP, the other auth mechanisms.

    These are not easy because they seem to require callouts to app-logic in order to be useful in a production environment.  Assuming static/canned responses are okay, it might be okay to enable these auth mechanisms (via their features) for, e.g., unit-testing purposes.

> Still, I think we are pretty close now, from my perspective. As was discussed, the "keyboard-interactive" method is a completely generic one where the user is presented with a set of challenges and…

The problem with the current keyboard-interactive model is that each “response” is effectively a password, even if it’s not a password, in that it is the magic answer that the client needs to provide.  

Thus, all the responses SHOULD be, e.g., hashed, so that the value that needs to be provided isn’t in the clear.  In this sense, we could use the iana:crypt-hash type for the “response” node, pushing it to the administrator to configure the hashed values.

That said, if we’re leaning towards static/canned “keyboard-interactive” config being sold for, e.g., unit-testing, it would be easier on the administrator to leave the values in the clear.

> Like I said, the best example of a problem we were solving with these priorities was that when your SSH client has both "publickey" and "password" authentications supported and working and you conn…

I understand you’re trying to enable the client to know exactly the right auth mechanism to use first.  My last response was, effectively, “let’s NOT solve that problem, because it’s a minor optimization, saving just one round-trip."

My question before was (and still is), since you did this optimization before, did it really matter (to save that roundtrip), especially in the context of using the (very slow) keyboard-interactive method?

> So you have decided to keep it? In any case, its functionality should now be unambiguous.

Yes, and yes.

K.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 28 Apr 2021 22:19:04 +0000

Hi Juergen,

> right, which is complex. Hence my suggestion is to not model it at this

I tend to agree.  While I also agree with Michal that the “keyboard-interactive” model reflects RFC 4252, it doesn’t seem practical in a production environment to have canned prompts/responses beyond, e.g., developing unit tests.

Take, for instance, the two examples in https://tools.ietf.org/html/rfc4256#section-4.  

The first example attempts to authenticate a crypto card, presumably by getting it to perform a private-key operation over the “challenge”.   However, in a production environment, the challenge would have to a random value each time (i.e., a nonce) as, otherwise it’s susceptible to a replay attack.

The second example reflects the case of an expiring password and the need to generate a new one.  First, passwords don’t expire *all* the time, so having static config doesn’t make sense.  Second, there’s no way to predict the new password value, and hence the “response” could not be configured.  Third, in order to apply the password-change, app-logic (e.g., a callout) would be need (e.g., to update a user database entry).

Michal, you said that you used “keyboard-interactive” before.  Can you please provide a concrete example?  Hopefully something beyond just prompting for a password, which I contend SHOULD use the “password” auth method instead...

> client side, the user is an account on the remote system.

Yes, they are different things.

> dealt with once there is more implementation experience.

Exactly what is likely needed for a production environment.  RFC 7317 includes RADIUS-client config, which we could embrace and extend (to support other mechanisms, e.g., LDAP, PAM, etc.), but this gets into the “more complicated than I want for now” teritory.  

My thinking, again, is to:

    1) enable "static user auth” to define a simple/built-in user database with static/canned auth configs.

    2) enable the “static user auth” tree to be disabled, so better (production-grade) mechanisms can be augmented-in.

K.

---

From: Michal Vaško <[email-masked]>
Date: Thu, 29 Apr 2021 07:40:58 +0200

Hi Kent,

> Thus, all the responses SHOULD be, e.g., hashed, so that the value that needs to be provided isn’t in the clear.  In this sense, we could use the iana:crypt-hash type for the “response” node, pushi…

That is true and would make sense.

> That said, if we’re leaning towards static/canned “keyboard-interactive” config being sold for, e.g., unit-testing, it would be easier on the administrator to leave the values in the clear.

I do not really see the point of having the configuration there just for testing purposes. With all the feedback provided, it seems to me now that all the configuration of "keyboard-interactive" should be scratched and leave it just as a presence container to allow augments. With a description mentioning them and the possibility of using PAM or similar authentication methods.

> My question before was (and still is), since you did this optimization before, did it really matter (to save that roundtrip), especially in the context of using the (very slow) keyboard-interactive…

But how is it saving just one round-trip? If you are offered "password" authentication but want to use "publickey" instead, let's say, you will likely leave the input empty just so that it fails and you get to the next method. But that causes a failed authentication attempt, if nothing else, which I do not think is that harmless.

Regards,
Michal

---

From: Kent Watsen <[email-masked]>
Date: Thu, 29 Apr 2021 13:48:07 +0000

Hi Michal,

> I do not really see the point of having the configuration there just for testing purposes. With all the feedback provided, it seems to me now that all the configuration of "keyboard-interactive" sh…

Could provide how you used “keyboard-interactive” before?  Was config such as in the current model used, or was it actually interacting with an PAM-like mechanism?

> But how is it saving just one round-trip? If you are offered "password" authentication but want to use "publickey" instead, let's say, you will likely leave the input empty just so that it fails an…

I’m unsure if you understand the SSH protocol, so here goes:  the client starts off with an auth method.  It can optimistically pick one (e.g., if it only has one to choose, then it has nothing to lose by picking it) or pick “none”.   In either case, if the server is unhappy with the method selected by the client (and it always will be when “none” is selected), the server responds with a list of “productive” methods the client should try next.  

The question is, how important is the ability to configure a “first” method (assuming more than one has been configured)?

My guess is that it’s not important as follows:

1) I assume the client is not resource-constrained (as, if it were, then it would likely be using TLS instead of SSH).  Thus, in the worst case, where the client performs some expensive key operation, it’s not a big deal because it has the resources to do it quickly.

2) Assuming the client sends an “expensive method” first, and the server isn’t configured to support that method first, it will not waste any CPU cycles doing an expensive key operation; it will simple return a failure with a list of “productive” methods.

Thus the net-impact is some wasted CPU-cycles on the client and the latency incurred by one unnecessary roundtrip.  Assuming the client is not resource-constrained, the only significant variable is the network and, in a very high-latency network, it could be important.  Thoughts?

K.

---

From: Michal Vaško <[email-masked]>
Date: Thu, 29 Apr 2021 16:56:35 +0200

Hi Kent,

> Could provide how you used “keyboard-interactive” before?  Was config such as in the current model used, or was it actually interacting with an PAM-like mechanism?

Currently, we do not use PAM but directly ask for the user password for the "keyboard-interactive" method. But it seems to me this may be wrong and definitely not the intended use so I will probably rewrite it once these modules are published and we are migrating to them.

> Thus the net-impact is some wasted CPU-cycles on the client and the latency incurred by one unnecessary roundtrip.  Assuming the client is not resource-constrained, the only significant variable is…

I am not sure what the problem is but it seems we are still not understanding each other. My specific example is as follows. The client uses "none" method first to get the list of supported methods, always. Then, based on the returned methods, it gets the set of supported methods on both the server and the client. The problem is, what should be the order of trying to authenticate using these methods? Like I said before, if a more complex method is selected instead of a simpler one, it may result in additional failed authentication attempt (and client disconnect if none are allowed), minor user annoyance, and even wasted server CPU time, yes. I consider the first problem serious enough that would like the module to support configuration that could prevent it.

Regards,
Michal

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Apr 2021 17:09:28 +0200

> I am not sure what the problem is but it seems we are still not understanding each other. My specific example is as follows. The client uses "none" method first to get the list of supported methods…

RFC 4252 says:

   The server drives the authentication by telling the client which
   authentication methods can be used to continue the exchange at any
   given time.  The client has the freedom to try the methods listed by
   the server in any order.  This gives the server complete control over
   the authentication process if desired, but also gives enough
   flexibility for the client to use the methods it supports or that are
   most convenient for the user, when multiple methods are offered by
   the server.

So the client does have to choose. Looking into the ssh(1) man page of
OpenSSH, I find this:

   The methods available for authentication are: GSSAPI-based authentica-
   tion, host-based authentication, public key authentication, challenge-re-
   sponse authentication, and password authentication.  Authentication meth-
   ods are tried in the order specified above, though
   PreferredAuthentications can be used to change the default order.

And ssh_config(5) says:

   Specifies the order in which the client should try authentication
   methods.  This allows a client to prefer one method (e.g.
   keyboard-interactive) over another method (e.g. password).  The
   default is:

I have no idea how popular it is to change the default order, which is
likely what most people expect.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Apr 2021 17:14:04 +0200

> likely what most people expect.

Let me add that an implementation that does password before publickey
would be somewhat annoying. In other words, I have no opinion whether
this order needs to be made configurable but perhaps it is meaningful
to spell out a default order that implementors should consider.

/js

---

From: Michal Vaško <[email-masked]>
Date: Thu, 29 Apr 2021 20:05:08 +0200

> to spell out a default order that implementors should consider.

Fair enough, that sounds reasonable and I suppose the default order should cover the majority of use-cases.

Michal

---

From: Kent Watsen <[email-masked]>
Date: Thu, 29 Apr 2021 18:35:45 +0000

>   most convenient for the user, when multiple methods are offered by

And the RFC goes on to say:

All of the methods returned SHOULD be productive for the client to choose next.  It doesn’t matter (from a protocol perspective) which method is selected, assuming more than one was returned.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 29 Apr 2021 18:36:16 +0000

> On Apr 29, 2021, at 2:05 PM, Michal Vaško <[email-masked]> wrote:
> 

How about this (the last sentence), in ietf-ssh-client?

        The credentials are unordered.  Clients may initially send
         any configured method or, per RFC 4252, Section 5.2, send
         the 'none' method to prompt the server to provide a list
         of productive methods.  Whenever a choice amongst methods
         arises, implementations SHOULD use a default ordering that
         prioritizes automation over human-interaction.

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Apr 2021 21:02:09 +0200

>          prioritizes automation over human-interaction.

I find the terminology at several places confusing. We have been
talking about the order in which user authentication methods are
tried. This has nothing to do with 'credential' ordering.

In draft-ietf-netconf-ssh-client-server-23.txt, I see

   *  The "client-identity" node configures a "username" and
      credentials, each enabled by a "feature" statement defined in
      Section 3.1.1.

Why is this called 'client-identity', should this note be called
user-authentication instead to align with SSH terminology? The
guarding features likely also should have different names:
client-identity-publickey -> userauth-publickey
client-identity-password -> userauth-password
client-identity-hostbased -> userauth-hostbased
client-identity-none -> userauth-none

I have not reviewed the entire document, I only search for specific
pieces of information, hence I am only commenting on what I found.

/js