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

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Apr 27, 2021 at 02:24:41PM +0000, Kent Watsen wrote:
> 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).
>

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

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
 
> 
> > On Apr 27, 2021, at 3:32 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> > 
> > 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
> > 
> > On Tue, Apr 27, 2021 at 08:58:42AM +0200, Michal Vaško wrote:
> >> 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 <[e-mail]> wrote: 
> >> 
> >>> On Mon, Apr 26, 2021 at 05:06:48PM +0000, Kent Watsen wrote:
> >>>> 
> >>>> * 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.
> >>>> 
> >>> 
> >>> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax:   [phone]         <https://www.jacobs-university.de/>
> >>> 
> >>> _______________________________________________
> >>> netconf mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/netconf
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> 

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