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

Kent Watsen <kent+ietf@watsen.net> Tue, 27 April 2021 14:24 UTC

Return-Path: <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF113A0BF6 for <netconf@ietfa.amsl.com>; Tue, 27 Apr 2021 07:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtUUFL9ku3kk for <netconf@ietfa.amsl.com>; Tue, 27 Apr 2021 07:24:42 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FBE3A0BFC for <netconf@ietf.org>; Tue, 27 Apr 2021 07:24:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619533481; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=LVyakDihnSYKlP9kVMYfbEKbI36VWYOtL0jsWru35jA=; b=HUB1lkbd4942y+Jm3Byj4Yuutcurj7MWcdcOnVsv0DkmMHPbKssH0nuGfEiqpdP2 IkXTWrj7IBogb2JaPDddtZLmAhwYudsNZS1oBrmDl1VnOYWtaWSR3Jv4k0XvstBIVqx 2TYbOGZrfDu7dTxOiye1aafZqA5XCA6TkzkCZuUA=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de>
Date: Tue, 27 Apr 2021 14:24:41 +0000
Cc: Michal Vaško <mvasko@cesnet.cz>, "netconf@ietf.org" <netconf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@email.amazonses.com>
References: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> <78fd-6087b600-7b-59cd2c00@214199368> <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2021.04.27-54.240.8.83
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0RDV57wStP7Wczx2dmhUr-B8jlY>
Subject: Re: [netconf] Latest ietf-netconf-server draft and related modules
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2021 14:24:47 -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 <j.schoenwaelder@jacobs-university.de> 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 <j.schoenwaelder@jacobs-university.de> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>>> 
>>> _______________________________________________
>>> netconf mailing list
>>> netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
> 
> -- 
> 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/>