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

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Apr 29, 2021 at 06:36:16PM +0000, Kent Watsen wrote:
> 
> 
> > On Apr 29, 2021, at 2:05 PM, Michal Vaško <[e-mail]> wrote:
> > 
> > On Thursday, April 29, 2021 17:14 CEST, Juergen Schoenwaelder <[e-mail]> wrote:
> > 
> >> On Thu, Apr 29, 2021 at 05:09:28PM +0200, Juergen Schoenwaelder wrote:
> >>> 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:
> >>> 
> >>>             gssapi-with-mic,hostbased,publickey,
> >>>             keyboard-interactive,password
> >>> 
> >>> I have no idea how popular it is to change the default order, which is
> >>> 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.
> > 
> > Fair enough, that sounds reasonable and I suppose the default order should cover the majority of use-cases.
> > 
> > Michal
> 
> 
> 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.
>

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>