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

Michal Vaško <mvasko@cesnet.cz> Mon, 26 April 2021 06:31 UTC

Return-Path: <mvasko@cesnet.cz>
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 9FE433A0D12 for <netconf@ietfa.amsl.com>; Sun, 25 Apr 2021 23:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=cesnet.cz
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 9UqxT-ivXhZh for <netconf@ietfa.amsl.com>; Sun, 25 Apr 2021 23:31:07 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FD33A0D05 for <netconf@ietf.org>; Sun, 25 Apr 2021 23:31:04 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 1F67360089; Mon, 26 Apr 2021 08:30:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619418655; bh=lnmA74ayf/4ElOQ6/KXG2BIiwHDxaBYRbFFlSfcNIsg=; h=From:In-Reply-To:Date:Cc:To:Subject; b=Ov4vL7uWBwNDj4rWLZcVWBvGf12zvLO3erMbGQ4oOY4C9RcVu+NLF3wqgAlUxs2L8 sgCf/taKNsT3cDLOyn7vCdMs6MXM5DCsnvnbr1zDXP6wqrylMptYNYGhDGsdv0u/DP YlF2jsdxelfbRX46Hjz1Hwg+/rQaMAA/pp/ccxb4=
From: Michal Vaško <mvasko@cesnet.cz>
In-Reply-To: <0100017900dd3b3b-d9ba3e7f-9f22-4fca-9060-da74b305fc4f-000000@email.amazonses.com>
Content-Type: text/plain; charset="utf-8"
X-Forward: 84.42.188.124
Date: Mon, 26 Apr 2021 08:30:55 +0200
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: Kent Watsen <kent+ietf@watsen.net>
MIME-Version: 1.0
Message-ID: <10f7-60865e00-73-1b8071a0@204658236>
User-Agent: SOGoMail 5.1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/vBgT8ny1fDYtCESWkTi8DT5c4zg>
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: Mon, 26 Apr 2021 06:31:13 -0000

Hi Kent, 

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

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.

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

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

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.

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

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.

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

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