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

[Kent Watsen <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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/>