From nobody Thu Apr 1 08:14:21 2021 Return-Path: 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 DC2083A177E for ; Thu, 1 Apr 2021 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 yIoS-9EUA-Yj for ; Thu, 1 Apr 2021 08:14:15 -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 DA9523A177D for ; Thu, 1 Apr 2021 08:14:14 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id CB2AC6009E; Thu, 1 Apr 2021 17:14:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1617290046; bh=q8b/TwQ2y7CGET4mPtzwOivnHi4gMF+OQYuuksrPzbQ=; h=From:To:Date:Subject; b=uPfys8eUHffmNj8RlURvBG/VaEx12AzFblQPtun2kwDz/tPJQjnP2kWa6e1h+eHPI nwSGP0lIQHXdnbY8U3P0OY5lsoVeuBISOX+PNwC0NKD+06UeaOGlzKa/2hPU5aNxXi LZx68OPVDGoPRz7iZ+nyJsHQxiGHmIQdOp2XL86M= From: =?utf-8?q?Michal_Va=C5=A1ko?= To: "netconf" User-Agent: SOGoMail 5.0.1 MIME-Version: 1.0 Date: Thu, 01 Apr 2021 17:14:06 +0200 Message-ID: <5303-6065e300-21-62233d80@261934342> X-Forward: 84.42.188.124 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netconf] YANG Push module errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 15:14:20 -0000 Hi, we are led to believe there is an error in the ietf-yang-push module pu= blished in RFC 8641 but I wanted to discuss it here before submitting a= n errata. There are 2 augments [1] on a notification that is conditiona= l on "configured" feature but these 2 augments are not conditional. Hav= ing this feature disabled, we were not able to load this module into ou= r tools. Does anyone disagree with this or with submitting an errata? Regards, Michal [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page From nobody Thu Apr 1 09:39:52 2021 Return-Path: <010001788e4e1852-363d7bb3-2022-4f3c-9d68-1c2fe51bcaa2-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 79A2A3A1AF9 for ; Thu, 1 Apr 2021 09:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vAI39K4RFP6v for ; Thu, 1 Apr 2021 09:39:47 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA493A1AED for ; Thu, 1 Apr 2021 09:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617295186; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Gn65SANamwI1W1nowM0BSKNDNLAcoN5aksfqxNUJjBM=; b=Tz0cpVouj99F4od4jmf9d8+LNai7G+C51SgbJU/y/eugUdvyWnhqfRfbqz0xkL82 HXg6fl/Jxs2l0xBFyBiv5C2DHHgBQEQAo70zgFZ78jji26oWXkBeougZU7qMVzO8yjr BKtdsJ0LUzHxE/cNIdW226Y0AiJsdjmX+QGeSwbg= From: Kent Watsen Message-ID: <010001788e4e1852-363d7bb3-2022-4f3c-9d68-1c2fe51bcaa2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6AC52391-5938-413F-95A8-BE4EC37EF898" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 1 Apr 2021 16:39:46 +0000 In-Reply-To: <451-60617580-a3-57300800@87220951> Cc: "netconf@ietf.org" To: =?utf-8?Q?Michal_Va=C5=A1ko?= References: <451-60617580-a3-57300800@87220951> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.01-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-ssh-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 16:39:49 -0000 --Apple-Mail=_6AC52391-5938-413F-95A8-BE4EC37EF898 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Just back from PTO] Hi Michal, > Hi, >=20 > I have raised some questions regarding this draft on the 5th of March = and even though I got the email bounced back from netconf@ietf.org, I = did not get any replies and cannot find it in the archive. In any case, = the original email is below. Strange. Here=E2=80=99s my response from before: = https://mailarchive.ietf.org/arch/msg/netconf/4gXyyI5SB0jWVXz1qpOAlt1e-qM/= = Cheers, Kent >=20 > I had a chance to look at these modules again and have 2 questions = regarding some recent changes. >=20 > - ietf-ssh-server, = ssh-server-grouping/client-authentication/supported-authentication-methods= >=20 > Since the "other" leaf-list was removed there is no way to support = some other methods than those specified. I am not sure whether this was = the intention and if so, what is the reason for it? If nothing else, we = support "interactive" authentication method but there are some others = that I see no reason why they could not be used. For a robust and = extendible solution, why not use an identityref leaf-list with all the = methods as identities? One could then simply add new ones with specific = "if-feature" statements. >=20 > - ietf-netconf-server, grouping = netconf-server-grouping/client-identity-mappings >=20 > The "if-feature" on this container is strange. The practical problem = is that if one wants to support certificates only for TLS, both one of = the TLS features and "ssh-x509-certs" must be enabled. This then results = in the container being defined for both SSH and TLS so there is no way = to support it only for TLS or SSH. >=20 > Thanks for any input. >=20 > Regards, > Michal >=20 > On Friday, March 26, 2021 23:30 CET, Mahesh Jethanandani = wrote:=20 >=20 >> We are starting a 2 week WGLC for = draft-ietf-netconf-ssh-client-server version 23. >>=20 >> = https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ = >>=20 >> Please respond on this thread indicating your support or concerns = about why this document should/should not be adopted. >>=20 >> We are particularly interested in statement of the form: >>=20 >> - I have reviewed the draft and found no issues.=20 >> - I have reviewed the draft and found the following issues =E2=80=A6 >>=20 >> This WGLC will conclude on Friday, April 9. An IPR call will be = issued separately. >>=20 >> Thank you. >>=20 >> Mahesh & Kent (as co-chairs) >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_6AC52391-5938-413F-95A8-BE4EC37EF898 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[Just back from PTO]

Hi Michal,


Hi,

I have = raised some questions regarding this draft on the 5th of March and even = though I got the email bounced back from netconf@ietf.org, I did = not get any replies and cannot find it in the archive. In any case, the = original email is below.

Strange.  Here=E2=80=99s my response from =  before: https://mailarchive.ietf.org/arch/msg/netconf/4gXyyI5SB0jWVXz1q= pOAlt1e-qM/

Cheers,
Kent




I = had a chance to look at these modules again and have 2 questions = regarding some recent changes.

- = ietf-ssh-server, = ssh-server-grouping/client-authentication/supported-authentication-methods=

Since the "other" leaf-list was removed = there is no way to support some other methods than those specified. I am = not sure whether this was the intention and if so, what is the reason = for it? If nothing else, we support "interactive" authentication method = but there are some others that I see no reason why they could not be = used. For a robust and extendible solution, why not use an identityref = leaf-list with all the methods as identities? One could then simply add = new ones with specific "if-feature" statements.

- ietf-netconf-server, grouping = netconf-server-grouping/client-identity-mappings

The "if-feature" on this container is strange. The practical = problem is that if one wants to support certificates only for TLS, both = one of the TLS features and "ssh-x509-certs" must be enabled. This then = results in the container being defined for both SSH and TLS so there is = no way to support it only for TLS or SSH.

Thanks for any input.

Regards,
Michal

On Friday, March 26, 2021 = 23:30 CET, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

We are starting a 2 week = WGLC for draft-ietf-netconf-ssh-client-server version 23.

https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-= server/ <https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/>

Please respond on this thread = indicating your support or concerns about why this document = should/should not be adopted.

We are = particularly interested in statement of the form:

- I have reviewed the draft and found no issues.
- I have reviewed the draft and found the following issues = =E2=80=A6

This WGLC will conclude on = Friday, April 9. An IPR call will be issued separately.

Thank you.

Mahesh & Kent (as = co-chairs)







_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_6AC52391-5938-413F-95A8-BE4EC37EF898-- From nobody Thu Apr 1 09:50:32 2021 Return-Path: <010001788e57d883-0be8fa5c-0435-4e63-bac2-911ef2947bfa-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 EADF83A1B45 for ; Thu, 1 Apr 2021 09:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MN1lcNb0RTvV for ; Thu, 1 Apr 2021 09:50:26 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1A93A1B40 for ; Thu, 1 Apr 2021 09:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617295825; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=odgSb7AE3QLFP6vFI+TjZPIE9bxFz1gZdsCWZ0ABKd0=; b=iMXMKHSxc8NLU8z8wjT5QLpJ7Mzs1wIN2tyebIFaFRGXx+9cIxxZmc55ynDo5YSc C4nmZEb5QRwMPlnKuvWjx2eQFbrhxl9B96DyESpoWIwlej8A4TfGrTTQiRBaOY+2gRK Mdhawo6nvf2uGI9HpohWVUpdk9jxyiGzEYL8J+r4= 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 In-Reply-To: Date: Thu, 1 Apr 2021 16:50:25 +0000 Cc: =?utf-8?Q?Michal_Va=C5=A1ko?= , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001788e57d883-0be8fa5c-0435-4e63-bac2-911ef2947bfa-000000@email.amazonses.com> References: <3bf7-60471b00-55-203315c0@163861349> To: "Eric Voit (evoit)" X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.01-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] RFC 8639 configured subscriptions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 16:50:31 -0000 Hi Michal, The =E2=80=9Chttps-notif=E2=80=9D and =E2=80=9Cudp-notif=E2=80=9D drafts = moving through the WG enable *configured* subscriptions to be delivered. So far there seems to be no interest in publishing a standard for = RESTCONF or NETCONF based *configured* subscriptions. =20 That said, it=E2=80=99s pretty easy to configure a RC/NC =E2=80=9Ccall-hom= e=E2=80=9D connection over which the call-home client (i.e., the = NMS/Orchestrator) immediately initiates a *dynamic=E2=80=9D subscription = for notifications. Cheers, Kent > On Mar 9, 2021, at 10:24 AM, Eric Voit (evoit) = wrote: >=20 > Hi Michal, >=20 > There is nothing which halts an implementation. The question really = is someone wanting to push the rest of the rest of NETCONF Configured = Subscription requirements through the IETF process. It shouldn't = controversial to complete the work. But the IETF process is always time = consuming. >=20 > Eric >=20 >> From: Michal Va=C5=A1ko, March 9, 2021 1:51 AM >>=20 >> Hi Eric, >>=20 >> I appreciate the help but what is the official situation then? >> NETCONF/RESTCONF has RFCs only for dynamic subscriptions so for these >> protocols configured subscriptions are not supported? Actually, there = are no >> protocols that support it, currently? >>=20 >> Michal >>=20 >> On Monday, March 08, 2021 18:06 CET, "Eric Voit (evoit)" = >> wrote: >>=20 >>> Hi Michal, >>>=20 >>> Configured subscriptions for NETCONF was originally in RFC-8640. = But >>> the draft was rescoped to just dynamic subscriptions by the time it >>> was published. >>>=20 >>> So it might be worth looking through: >>> = https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notificat >>> ions-1 >>> 0 >>> This version does include the module you request below. Also = included >>> is other text which might be of interest. >>>=20 >>> Eric >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: netconf On Behalf Of Michal Va=C5=A1= ko >>>> Sent: Monday, March 8, 2021 10:17 AM >>>> To: netconf >>>> Subject: [netconf] RFC 8639 configured subscriptions >>>>=20 >>>> Hi, >>>>=20 >>>> we want to implement both dynamic and configured subscriptions for = a >>>> NETCONF server. Reading through the RFC, it is pretty clear that = the >>> configured >>>> subscriptions require a YANG module with NETCONF-specific = parameters >>>> including a "netconf" identity derived from the "transport" = identity >>>> (juts >>> like the >>>> "foo" example[1]). We have not managed to find such a module, does >>>> it >>> exist? If >>>> not, could someone provide some more information about how it can = be >>>> implemented? Thank you. >>>>=20 >>>> Regards, >>>> Michal >>>>=20 >>>> [1] https://tools.ietf.org/html/rfc8639#appendix-A >>>>=20 >>>> _______________________________________________ >>>> netconf mailing list >>>> netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Apr 1 17:21:51 2021 Return-Path: <010001788ff509c3-162795df-4755-4dc7-b7e6-a566cf55b12e-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 AAFBE3A2970 for ; Thu, 1 Apr 2021 17:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 629pJmaXd7qK for ; Thu, 1 Apr 2021 17:21:45 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EF03A296E for ; Thu, 1 Apr 2021 17:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617322904; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BbWgShaRRhYDzJWlR0P6ir6L9h5G8Qy4C9MIuBrnMB0=; b=kq7b8HxfRsuuX94iubJmKWlDZdk3G2pz1vhxUF6gTiSy5G5Yj22ss1nWXP7Xohxq 5sEB2WP3fBO8+i9XdTJTUmSMBZ9NCm012wJ426cKYEf/J3cTuE5neHq39xQvG7CseEn BOL3rnIEhwdEdGoJROi2zXq+vN4fGDSW1ho/8vlc= From: Kent Watsen Message-ID: <010001788ff509c3-162795df-4755-4dc7-b7e6-a566cf55b12e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F94DE9E1-D70E-4A7E-9F57-A701559BB4DA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 2 Apr 2021 00:21:44 +0000 In-Reply-To: <1A980A66-12AA-439F-976E-F73C5A274320@gmail.com> Cc: "netconf@ietf.org" To: Mahesh Jethanandani References: <1A980A66-12AA-439F-976E-F73C5A274320@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.02-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] IPR poll for draft-ietf-netconf-tcp-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 00:21:50 -0000 --Apple-Mail=_F94DE9E1-D70E-4A7E-9F57-A701559BB4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, I'm not aware of any IPR that applies to this draft. Kent > On Mar 30, 2021, at 5:36 PM, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, WG, >=20 > As part of WGLC on this document: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. >=20 > Also please send the response to the list above, and not unicast it. >=20 > Thanks. >=20 > Mahesh Jethanandani (as co-chair) > mjethanandani@gmail.com >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_F94DE9E1-D70E-4A7E-9F57-A701559BB4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii No, = I'm not aware of any IPR that applies to this draft.

Kent



On Mar = 30, 2021, at 5:36 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Authors, Contributors, = WG,

As part of WGLC on this document:

Are you aware of any IPR that applies to draft = identified above?

Please state either:

"No, I'm not aware of any IPR that applies to = this draft"
or
"Yes, I'm aware of IPR that = applies to this draft"

If so, has this IPR = been disclosed in compliance with IETF IPR rules
(see RFCs = 3669, 5378 and 8179 for more details)?

If = yes to the above, please state either:

"Yes, = the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any = additional details you think
appropriate.

If you are listed as a document author or contributor please = answer the
above by responding to this email regardless of = whether or not you are
aware of any relevant IPR. This = document will not advance to the next
stage until a = response has been received from each author.

Also please send the response to the list above, and not = unicast it.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com






_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_F94DE9E1-D70E-4A7E-9F57-A701559BB4DA-- From nobody Thu Apr 1 17:22:14 2021 Return-Path: <010001788ff553ed-6ee306b2-7d99-4a45-bda7-dd8c0a94943d-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 BF7A03A296D for ; Thu, 1 Apr 2021 17:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 lV2FbS8ooRyw for ; Thu, 1 Apr 2021 17:22:08 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF4E3A2975 for ; Thu, 1 Apr 2021 17:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617322923; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=h6jy28SrucWTNBk5p1BMJ7rqTtueSDfrqOxG/KYm9xc=; b=jFqs693o/0OTrjrCJo+ORw0ZcXu6e2S/gQ5mPVUZsr+4qMNOljrSM4jaP6SBkUxm 4Kthj0rtdi//PWQWECG2K+psd2Ttuv2xwyzXTd4cm+tkdrZ+qSWBkd7ru6Zh0OZa4u/ uymqAPjOnPAFptZl2SRCBn6paS0G4ldIa71Gv9ps= From: Kent Watsen Message-ID: <010001788ff553ed-6ee306b2-7d99-4a45-bda7-dd8c0a94943d-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_89405EB5-A1D5-4F42-96E3-11C43B790828" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 2 Apr 2021 00:22:03 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Mahesh Jethanandani References: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.02-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] IPR poll for draft-ietf-netconf-tls-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 00:22:13 -0000 --Apple-Mail=_89405EB5-A1D5-4F42-96E3-11C43B790828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, I'm not aware of any IPR that applies to this draft. Kent > On Mar 30, 2021, at 5:36 PM, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, WG, >=20 > As part of WGLC on this document: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. >=20 > Also please send the response to the list above, and not unicast it. >=20 > Thanks. >=20 > Mahesh Jethanandani (as co-chair) > mjethanandani@gmail.com >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_89405EB5-A1D5-4F42-96E3-11C43B790828 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii No, = I'm not aware of any IPR that applies to this draft.
Kent

On Mar 30, 2021, at 5:36 PM, = Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Authors, Contributors, = WG,

As part of WGLC on this document:

Are you aware of any IPR that applies to draft = identified above?

Please state either:

"No, I'm not aware of any IPR that applies to = this draft"
or
"Yes, I'm aware of IPR that = applies to this draft"

If so, has this IPR = been disclosed in compliance with IETF IPR rules
(see RFCs = 3669, 5378 and 8179 for more details)?

If = yes to the above, please state either:

"Yes, = the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any = additional details you think
appropriate.

If you are listed as a document author or contributor please = answer the
above by responding to this email regardless of = whether or not you are
aware of any relevant IPR. This = document will not advance to the next
stage until a = response has been received from each author.

Also please send the response to the list above, and not = unicast it.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com






_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_89405EB5-A1D5-4F42-96E3-11C43B790828-- From nobody Thu Apr 1 17:22:26 2021 Return-Path: <010001788ff57cc8-c296e106-3b3c-4013-a5bd-6dab3481d5c6-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 47C543A2995 for ; Thu, 1 Apr 2021 17:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dIVhFe2K1IZM for ; Thu, 1 Apr 2021 17:22:14 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FA13A2972 for ; Thu, 1 Apr 2021 17:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617322933; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=R9slTd9YuCB3Zrs5QX1PtEsDxbPV89+KbnllEKVmJgU=; b=GJohMyEsdLi2Q+23rBL/XmmPM6Wst/8nGgF8sA6TO6B4n2uFgP5Tk4exikLYdhp6 +/A2im5OYw7bqyYfTZa7PS7QEW09KNkk9oILo3M9vqvke9qMSMgWzZEpd7UAF+P4RHA otUjo/2vNwVWpchiZs3ebzQ6K0EcPMk3fLb313cE= From: Kent Watsen Message-ID: <010001788ff57cc8-c296e106-3b3c-4013-a5bd-6dab3481d5c6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FB4A6E0E-12D8-44DF-BCBC-482A9D8EB19D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 2 Apr 2021 00:22:13 +0000 In-Reply-To: <750678AF-7392-4E50-96FD-9EC65C827AC6@gmail.com> Cc: "netconf@ietf.org" To: Mahesh Jethanandani References: <750678AF-7392-4E50-96FD-9EC65C827AC6@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.02-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] IPR poll for draft-ietf-netconf-ssh-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 00:22:25 -0000 --Apple-Mail=_FB4A6E0E-12D8-44DF-BCBC-482A9D8EB19D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, I'm not aware of any IPR that applies to this draft. Kent > On Mar 30, 2021, at 5:36 PM, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, WG, >=20 > As part of WGLC on this document: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. >=20 > Also please send the response to the list above, and not unicast it. >=20 > Thanks. >=20 > Mahesh Jethanandani (as co-chair) > mjethanandani@gmail.com >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_FB4A6E0E-12D8-44DF-BCBC-482A9D8EB19D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii No, = I'm not aware of any IPR that applies to this draft.
Kent

On Mar 30, 2021, at 5:36 PM, = Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Authors, Contributors, = WG,

As part of WGLC on this document:

Are you aware of any IPR that applies to draft = identified above?

Please state either:

"No, I'm not aware of any IPR that applies to = this draft"
or
"Yes, I'm aware of IPR that = applies to this draft"

If so, has this IPR = been disclosed in compliance with IETF IPR rules
(see RFCs = 3669, 5378 and 8179 for more details)?

If = yes to the above, please state either:

"Yes, = the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any = additional details you think
appropriate.

If you are listed as a document author or contributor please = answer the
above by responding to this email regardless of = whether or not you are
aware of any relevant IPR. This = document will not advance to the next
stage until a = response has been received from each author.

Also please send the response to the list above, and not = unicast it.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com




_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_FB4A6E0E-12D8-44DF-BCBC-482A9D8EB19D-- From nobody Thu Apr 1 17:22:40 2021 Return-Path: <010001788ff5be57-aaf09a9e-b91b-4eaa-8850-f833cb2cf7d6-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 EF8CB3A298D for ; Thu, 1 Apr 2021 17:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4NRP0F6vfSf0 for ; Thu, 1 Apr 2021 17:22:33 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9830F3A2995 for ; Thu, 1 Apr 2021 17:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617322950; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Mx7fUrmJmganvUOVWI9JTTuCABusCGB2aYseHFJ8SxA=; b=UV7wkhDY1AeNavSna+O/K2SoWcfc+uLHVfXcdHC0ucFI88YGV2n2rQw0CYuWm2hP JptJBOZlYp+QxaDzX47MTL2hHAmm1qvFMdRiuUc/JN2YMYaaPjonc9qZ0W8qp29kTzn UrmjWr0owIeq3bp4sYMEgSWA0VDCfwDuwpcr9NaY= From: Kent Watsen Message-ID: <010001788ff5be57-aaf09a9e-b91b-4eaa-8850-f833cb2cf7d6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F18E4B0-3A9B-4E70-B90C-478527FF60A5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 2 Apr 2021 00:22:30 +0000 In-Reply-To: <84EEA6E2-3323-47A0-8C5D-F0B3AA013EA7@gmail.com> Cc: "netconf@ietf.org" To: Mahesh Jethanandani References: <84EEA6E2-3323-47A0-8C5D-F0B3AA013EA7@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.02-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] IPR poll for draft-ietf-netconf-http-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 00:22:39 -0000 --Apple-Mail=_3F18E4B0-3A9B-4E70-B90C-478527FF60A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No, I'm not aware of any IPR that applies to this draft. Kent > On Mar 30, 2021, at 5:36 PM, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, WG, >=20 > As part of WGLC on this document: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. >=20 > Also please send the response to the list above, and not unicast it. >=20 > Thanks. >=20 > Mahesh Jethanandani (as co-chair) > mjethanandani@gmail.com >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_3F18E4B0-3A9B-4E70-B90C-478527FF60A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii No, = I'm not aware of any IPR that applies to this draft.
Kent

On Mar 30, 2021, at 5:36 PM, = Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Authors, Contributors, = WG,

As part of WGLC on this document:

Are you aware of any IPR that applies to draft = identified above?

Please state either:

"No, I'm not aware of any IPR that applies to = this draft"
or
"Yes, I'm aware of IPR that = applies to this draft"

If so, has this IPR = been disclosed in compliance with IETF IPR rules
(see RFCs = 3669, 5378 and 8179 for more details)?

If = yes to the above, please state either:

"Yes, = the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any = additional details you think
appropriate.

If you are listed as a document author or contributor please = answer the
above by responding to this email regardless of = whether or not you are
aware of any relevant IPR. This = document will not advance to the next
stage until a = response has been received from each author.

Also please send the response to the list above, and not = unicast it.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com






_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_3F18E4B0-3A9B-4E70-B90C-478527FF60A5-- From nobody Fri Apr 2 06:44:28 2021 Return-Path: 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 BE79A3A1738 for ; Fri, 2 Apr 2021 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kVkBmn7T; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=dlsNlzoa 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 okPb6oGOpsD9 for ; Fri, 2 Apr 2021 06:44:22 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A168F3A1739 for ; Fri, 2 Apr 2021 06:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7067; q=dns/txt; s=iport; t=1617371062; x=1618580662; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wNDEKaehmmtlxUDXmEHpRtsqiPYIMAU8H7ADiQwUNQ8=; b=kVkBmn7T2W6kZomMP/sOLJV9FXt9uF2v50C/JxHiz03QjhCWOLiNcBCv pXOr4i2AO46jBT5bmZQ42+N3g1fE/S2MSp0mzd30Le5VIUe3v5s5jBAWs vA0ZmEC1LdL9kclyGdLfwGDAlr1Iygx4x4S4D/+ZU3gHAJ0pMCpAjyPTg A=; X-Files: smime.p7s : 3975 X-IPAS-Result: =?us-ascii?q?A0A4BgBNHmdg/4ENJK1agQmBUoFTUQd3LC42MQqIAAOFO?= =?us-ascii?q?YhRA5k3gS6BJQNUBAcBAQEKAwEBHQsKAgQBAYQMRAKBfAIlNAkOAgMBAQEDA?= =?us-ascii?q?gMBAQEBAQUBAQECAQYEcROFUA2GRAEBAQQBAT4BASwLAQsEAgEIEQQBAS8CJ?= =?us-ascii?q?QsdCAIEDgUIBoJkgX5XAx8QAQ6gcQKKH3WBNIEBggQBAQaBNwKDbBiCDAcDB?= =?us-ascii?q?oE5gVOBI4pUJhyBSUKBVYJZPoJgAQECAYFdg0mCK4MlIT0CIDsxDLwfCoMKg?= =?us-ascii?q?R+DYIJwgXCTN6RtoHqSaIRRAgICAgQFAg4BAQaBVDqBWXAVO4JpUBcCDpIPh?= =?us-ascii?q?RSFRXM4AgYKAQEDCXyMXgGBDgEB?= IronPort-PHdr: A9a23:E2ls3xWtiHT7ALVEE7MWKfr292jV8K0OAWYlgqEPgq9Scqml45XpN VDe4vMollLSQIHH8JpsgOfNta38H2cSst6Ns3EHJZpLURJNycAbhBcpD8PND0rnZOXrYCo3E IUnNhdl8ni3PFITFJP4YFvf8Xa/9jgfBlP0J1k9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyI Ry6oB+XuNMRhN5pK706zV3CpX4bE9k= IronPort-HdrOrdr: A9a23:z1vs3K4nTJ91dxPSvQPXwZqFI+orLtY04lQ7vn1ZYSd+NuSFis Gjm+ka3xfoiDAXHEotg8yEJbPoexLh3LZPy800Ma25VAfr/FGpIoZr8Jf4z1TbdRHW3tV2kZ 1te60WMrLNJHBxh8ri/U2cG9Ev3NGI/MmT9Jjj5l1GJDsaDJ1IxQF/FwqdDwlSTA5JGZI2GP Onl7R6jhCnfmkaadn+O2kdU4H41pP2vb/FQTpDPR4o7wGSkSilgYSbLzG01goTOgk/uosK3n PCl2XCl8CemtG9jiTRzmrCq6lR8eGRtudrIOyppowrJi73igCuDb4RGoGqmDwuuumg5BILvb D30m0dFv9+4X/QYW25yCGFs2KLvVpeiA6B9XaijXTuusD/Tj4hYvAx+L5xSAfT6EYrobhHoc R29l+ZrJZeAFfhmynw9rHzJmlXv3e0unYrnKoviWVeW+IlGcZshLEYlXkldKsoLWbf0sQKAe NuBMbT6LJ9alWBdU3UuWFp3ZiFQmkzNg3ueDlDhuWllxxt2FxpxUoRw8IS2l0a8ogmdpVC7+ PYdox1ibB1SNMMZ64VPpZDfeKHTkj2BT7cOmObJlrqUIsdPWjWlpLx6LIpoManZYIP15l3vJ jaSltXuSoTdivVeI+z9awO1iqIbHS2XDzrxM0bzYN+oKfASL3iNjDGR0spl8emvvUDEszWU/ u+I/ttcrveBFqrPbwM8xz1WpFUJ3VbetYSoMwHV1WHpd+OKoCCjJ2dTN/jYJ7WVRo0UGL2BX UOGBLpIt9b00ytUnjkxBzYW3bnfF3j7Yt9eZKqudQ7+cwoDMlhowIVgVO26oWgMjtZqJE7e0 N4PffgiaO0pW6/+G7S9GV3Mh9BDkJYiY+QFk9ilEsvCQfZYLwDs9KQdSR5x32cPCJySMvQDU pCvVht4Lm2KJaR3CgmDNqiPguh/iIujUPPa61ZtryI5M/jdJ99M40vX7ZpEx7XUzZvnxxxlW tFYAgYZ0PWGz/0k5+5hJgMCOy3TaglvC6bZepv7VPWrwG1uNwmTHpzZU/ebeenxSIVAwdyqn I02akFm7aEkSuoMgIE8ZQFGWwJTn+WDrJABBmCf6NOlNnQCVpNZFbPoyCGgBcufWev0EMeig XaXHCpUMCOJEZBsXZF1auvyndITyG2ekJ9bW0Si/wmKU3Ppmtz3eiXZqC6zmuWbR8YzvsANS zeCAFiUT9G1pS50gWYly2FEmhjzpIyPvbFBLBmaL3L3GixQbf42J0uDrtR/Jx/MsrpvfJOWe WDexWNJDeQMZJj5yWF4nIkMjJzsn8qjLfh3wDk9nGx2Do6DeDJKFprA7EdLNf01Rmve9+YlJ F4h8kyp+2+LyH4bcOH07jea3pbMQzIyFTGOd0AuNRRp+Y/pbFzF57UXX/B02xGxgw3KIPxmF kFSKp27bjdMuZUDoAvUjMc+kBsmMWELUMtvACzGOM4cF03h3LQPt+C4dPz2PISK1zEoBG1NU iU8iVb8fuAQjCK0qQCDbksZWtRc0ox5R1Zjay/XpyVDB/vce5N/FC3aCDgNLBcTbWIArUWoF Jx5cqSk+qeair/30TRsFJAU9Zz2nfiRdn3BgSGXfNM+Zi9P1+Hh6Ox+s69jDvtU1KAGg0lrJ wAcVZVd9hJjzkpkZY+3SezQLHmu05NqSoq3Rh30lr2npW86GjVHUtaIRTUj5VfUz5UKGWJh6 3+gJ+l/WW45iNE15nFHFpRed8LG8F4dPmEExtT X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,299,1610409600"; d="p7s'?scan'208";a="673976199" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2021 13:44:21 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 132DiLsP012413 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 2 Apr 2021 13:44:21 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 2 Apr 2021 08:44:21 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 2 Apr 2021 08:44:20 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 2 Apr 2021 09:44:20 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ov6gaS9Q4geEFoNYGi69iqWIO2fQf2mbk28KYywIx6Ea4YcrAWpBJMR0Ca/ioVkla807MLHZh9zK1tYMPQ5L9qKm9Aqxc91DeLG35+MxAsOyZyXVS7CXo3/eftddwQDPSdHOt5/aeGfJhzpXo6G+84y2ALwi6nRN45wWsec7opcHv0H+IeWwr5JM/cJLQ5VbrMbYZ/HoLUchBW6W13em6eadU6xFJtroxig0No4+3ybAC+iKvX+FOD5XCZx/opcvG2vdDd05xKedB6peDIIDKBBKhjk/phb6J6k53knlsrZN3DyFXroMAoYy+GFSybJn/pBec2N3JBzLaSGE7UH0cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9qBWtezLCJSPm5El+7XuwyrsNnEpdkanVX/7Uqm/I68=; b=b27PmZKnafAprooqgL/WNCaTEhKBMJpBIbUA1dTwbCdP1q2Tq9OU9N2M55t0Gd/SNYG+sg7Ri3+0bSVhVqVtyziC0lcc3tPDC8TBcHkOjsNhu9mN3v+eKMZCOkZLYm3F3fUz21dizEF/A73lHURGhh8kkji9VLRhguBTffinJVRH1DVyAwU638LcFNcPkedHr0emI2A+UAs/QSxe0IcpxaB8uO8QILmVqoN1lM8aSGms6BDeLglZuf3CCWGS/oYyVCNKKqr8tg36dhUFOlG9/UJ9ete94zSE3JHX+/vDQWzZ1YWeCQpXPQ2EsKgoo5VUGnsF6MxuiE7UviqJ1XJHxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9qBWtezLCJSPm5El+7XuwyrsNnEpdkanVX/7Uqm/I68=; b=dlsNlzoazr67o9YO0otHQVzYtVMo6aPJ8dv9h6V6+Ikwb72gyScRZl8fMr/hmtx+W5sF0SqW3/zM4w43+/kUPXrxeIxkIX3UnBYnof0FYg4O0by8g8yFXJkIxR2UFJseQ5WSdxJKBRmZjX1hIHN/H8bhjB1OnaJGY+W7VvW3P1g= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL1PR11MB5333.namprd11.prod.outlook.com (2603:10b6:208:309::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.28; Fri, 2 Apr 2021 13:43:02 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::f571:5dd6:fe20:3ab0]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::f571:5dd6:fe20:3ab0%4]) with mapi id 15.20.3999.027; Fri, 2 Apr 2021 13:43:02 +0000 From: "Eric Voit (evoit)" To: =?iso-8859-2?Q?Michal_Va=B9ko?= CC: netconf Thread-Topic: [netconf] YANG Push module errors Thread-Index: AQHXJwm8L7kbPew7IEuWKBYzK1RF36qhPDFQ Date: Fri, 2 Apr 2021 13:43:02 +0000 Message-ID: References: <5303-6065e300-21-62233d80@261934342> In-Reply-To: <5303-6065e300-21-62233d80@261934342> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: cesnet.cz; dkim=none (message not signed) header.d=none;cesnet.cz; dmarc=none action=none header.from=cisco.com; x-originating-ip: [108.18.141.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c4211456-2872-4720-7d63-08d8f5dd3c64 x-ms-traffictypediagnostic: BL1PR11MB5333: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5S2SXF4b/KvB8F0akwmikgHPjyQYULADYQ4XKJ2liSh4Hm5jAaBqfQHmRRNRfwY93LpJd7NNfuz/OX7C2Gsx7MDEir+gB3wmdNzHj7gsfTtA3RCkUSMm2x68H7A0N4lp8yaT8wEEQPmDesax1mRx0UP63EWc1oGnbuVdKiLyNcICgA59R5P7bI2dZfepKDfhKC9iBVrjcuc1t2UeB4gdzeMmP0De+28pGaNaVa6ZR397HMgn1Zwqh0o5AOLfzKl+1KrOxM6Mrn4rFUlGzBajE5qdpZBVDX81ou9OAcjGQM8Aoo5mXe65Af30h8C6zdI4fEKr8KZsbhj9PGaBlXCW08JHmEyWm5qyg0btJ1gwn5ZZBZOpjiHmXNx10sevso3bUb2SHA1ypp8GdyXBb8UMfK1zEsWLSvpTEPrqR+W4H2hXYixHuSrqQAuWkCGdUlRTPrcCw0S96KR0WL84OZ3HbD0TOk3MipUyTNhE/AageFjmJy+DyfsFBpdMBer3AH8PFqNZskeCmAzp5oTaxaZeCWcNNxDB2FtBlPuZbTe8CAzmCl4r/LVGoy7ZfAPbJ+aX+EH8vHi3iA7BLWtvx6ds3nAbqlDE1M3Xi459lHLoLvexNNIDxDk700uwgWWcQkiHLLpKCC0Fjn74liNXSKbkRA2af/oy0lf8ZK2d6ohf0FQ7DpLtkQsYZ8bJXdMQ3Nrr/KD27p2k6mPZG2RItZ3+biOzSqgl+U9/RfgxOHIBv7E= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(376002)(39860400002)(136003)(366004)(2906002)(38100700001)(8936002)(6916009)(55016002)(8676002)(66616009)(186003)(4326008)(86362001)(9686003)(26005)(5660300002)(966005)(83380400001)(71200400001)(6506007)(478600001)(7696005)(53546011)(66574015)(99936003)(76116006)(33656002)(66446008)(66556008)(66476007)(66946007)(64756008)(52536014)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-2?Q?pV5l6byCyeizgE4BUJT7jie77ZanbIqwiDAoTlO8Rz4lfsCaxVONQQ9V9i?= =?iso-8859-2?Q?O9aWUrmcM3qNtQPn5MuP2RcUdUr8nZnT7rhOeP+3bSccIZW8hhkdRmb5EK?= =?iso-8859-2?Q?FaNSQCMTttLVdK/ENwBHBnZL9oYSJVyjnk4j/R5o9dUTGjE5L93WdclqWK?= =?iso-8859-2?Q?wkFjY9jJWnVeSCQr3olCJN6r7zG318bxeG1YMiNyiqi6v7fFb277aVIAcX?= =?iso-8859-2?Q?1gwGtL3iE86Q3bFjASkIOK6DVDS76rmI4wNbpTonEWJ5bXjNwg9EfUOhQ4?= =?iso-8859-2?Q?fETL659sfKTIGGNk3DC3TywA0ZDHDwmDr4x8hwW3NHWTof4f5+2F29yJW4?= =?iso-8859-2?Q?zvKtPpoQxSYdH1UqN0CGx62cvp25YBHVHrgHt3atUq2OZaYEx6o+54e8Nc?= =?iso-8859-2?Q?axpfHIjV1SKJDZUj99nQ86k0D7PxziutgKM2X5/mRF+RRgE86VkyzmRZ4l?= =?iso-8859-2?Q?F9d/ANgTtx8jf5GZeTpxf+GG+O1TK1J+v/DwIyIvLZGY/+NmHpcxKqfIeN?= =?iso-8859-2?Q?HoXDnQJ+TJPh+t8um8tUt5sa2LaUB/9r2XSwdc44Z3T0guXQQM7lGf6Fom?= =?iso-8859-2?Q?vVGqIvhILJv3n9gXb6vP+7x9e4L3v3FShk3YiLSFnEFFEJ3/JQ/CevZIL1?= =?iso-8859-2?Q?scZAzb5OXiWNTnH5ovLov6qwmxykJVnOqUZD44JmTYiifUpMC2a16rfT3A?= =?iso-8859-2?Q?0lA7N1MrWtBHaKts1fK/7NsUpZyRrTYc3AIZAA4H5H8BN5Ao2+xePdSGxc?= =?iso-8859-2?Q?ioJKGWvHbPnhHepoWk1/eliqStwUa49H+S2/h4FzQRQ8xtSBrx2FuMXTQv?= =?iso-8859-2?Q?M2n/5Tm7jJAdtd6NON4N1nLrx3F79jJA/XsyJmtlouN/l+JkrEMiQ42HHa?= =?iso-8859-2?Q?UOUOPc59K/Ktej3ph5vXabhuxHydz1uCXtoQRBLAUpwICDpVD5TDL5T8lz?= =?iso-8859-2?Q?BJfxyr8Gn++x8p0HeRj15oJY7fR6v4enmPgg6IFNprynfqbXhvWW0N19SM?= =?iso-8859-2?Q?dSd6raIfnVi3XRMuJyPRgd4oWAGB9dYFsXmjiMNWgO5OWqkVA6A73kbbwy?= =?iso-8859-2?Q?4zS7KuK466ow1iwmTB2oc3Mgnfr34gdHz4m9G7nosPriYmmYWnMzJfqCcw?= =?iso-8859-2?Q?HrNNgS7M9WkOjfLhDBrAoFXiRE43a+nyVZZzP1vk6e56W5O7i39jKgg/+X?= =?iso-8859-2?Q?YOHW7EvrqBLnR2bGvX+LY01jBCkPTq1r5hY3aGl2NCMbrU/ZXu3NA9l+Wh?= =?iso-8859-2?Q?1ykPh7C4f0btzuDaz3iEOk59NNq7cK7Wk13sJ0rz3zpHojCtVLQ3lm7ENH?= =?iso-8859-2?Q?AApRk72eIZ7amDETeeNeuYm6YSQrnDgtVRV0Bqj8Dbg/t+FPzjKmvkCBS/?= =?iso-8859-2?Q?vYxGpis51D?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_049F_01D727A4.92121F60" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4211456-2872-4720-7d63-08d8f5dd3c64 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2021 13:43:02.1352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wyX+Zuem5Q5MiHx4+Y+1QEyrtx0VNGNDdVDkNXu4GbXWwl5S5FEGsfit9gxb5HVH X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5333 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netconf] YANG Push module errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 13:44:27 -0000 ------=_NextPart_000_049F_01D727A4.92121F60 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Michal, This sounds like a tooling issue to me. I would expect that any = augments would inherit the conditional nature of anything augmented. =20 If you disagree, perhaps a thread to the netmod alias would get you an 'official' answer on the proper behavior. Eric > -----Original Message----- > From: netconf On Behalf Of Michal Va=B9ko > Sent: Thursday, April 1, 2021 11:14 AM > To: netconf > Subject: [netconf] YANG Push module errors >=20 > Hi, >=20 > we are led to believe there is an error in the ietf-yang-push module published in > RFC 8641 but I wanted to discuss it here before submitting an errata. There are 2 > augments [1] on a notification that is conditional on "configured" = feature but > these 2 augments are not conditional. Having this feature disabled, we were not > able to load this module into our tools. Does anyone disagree with = this or with > submitting an errata? >=20 > Regards, > Michal >=20 > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_049F_01D727A4.92121F60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGEgV4QUlW UJkwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTIxMDMxODExNDIxMVoXDTIzMDMwODExNTIxMVowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMr3OT5uPdoB sEI5qhFsZoXJUU2+kpGdfK9PjBUA2anlMWJyjFbr7HIkvMzPsh12JfQavJXQvTFIF0fvkky6YGlb yJszRm4mLDrVPxKA3HJWUUAEjYPJ82gKjo8IEvRm7C2meY89jYHH9VPZixtTyVhUUi0FjEp9GOhT 4tEZsMsOGGXwd7mF2h3RTfO/zKw+Bnwf4u8NdEYwY7OXeil09zGA7OYq2dcZfoNEXn2G5fLN7027 yP4c1woK2qijILgWWvo513xt7wCs+YwQv3EqmYXGjS/8vjQCiuX9o7VX1vwo5ZC8zYmfs4ghxqgE 4xk3rE7mQAshhiz/ZbX3wAMGXmUCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFLKIFX851DyED2YIZTAadd2qyZM2MB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB+JqPU4u+a CW/M1cTWK9db/lWFSyJMTJSMwXxSwOYRaP6+StWpWH9RFLLbuNAXpbTN/B17Ukte4H8972IVKqN7 3bw2KB8pjSfOB+AfryhVz3yNW9Bzd7qTqOvJuK39cebgLktxuqf/w3A+QqnrycH374BHQFI9K+4A NyQMJVDVpU/VjO2uemoleR3Cb3G4mRpLURMpQBCDNPoonRuWU1TyHpMyGDnqLP8S5FU0RvJ7P831 dfPf+VZPC9XeIYslPRqqvthpUOCUSzmNeNIn1ryEpO9AXIww+LvJGu7PWLEDdyT1So6om2rYgHTa /cj5uErlxb4bBHf5S3kILah5Yw5QMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGEgV4QUlWUJkwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwNDAyMTM0MzAwWjAjBgkqhkiG 9w0BCQQxFgQUG7R22JaaG9u95MnHvrA1fagwyRgwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGEgV4QUlWUJkwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYSBXhBSVZQmTCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAUFwBVD4/DP+jkJ3ggIgHrFiQI0v95iShn2wlUHMn7SHckUTgnbzZWJgZCj/gxuCUC sFOJHaUYAkubnjmoKCcdHtePZKa4FcVftwitm64BIQpnwL5w5Ide+8GkuhXi7I4v7KgunBgUHeaL ie7RXvqxnmf4wyPDoksUvJhPkg6yGclT81IS+1G3OsSuKOr2m9u+qN9uyAQTi28k3s+PLtCSiaA6 +vUTwl/0TOv/v1ml+mQAGfekthOi+l/y4S7Ng5DQ/pHoNMXFEQrAOzVp2PSGkXSh8s3dCR/b0qKp 6udOtZcaAa0pC298fofzoLjFVqjzG+M8QhaWG4d5e0WOG9ngAAAAAAAA ------=_NextPart_000_049F_01D727A4.92121F60-- From nobody Fri Apr 2 08:10:46 2021 Return-Path: <010001789322da54-a43f6e89-c6a6-4653-a878-1bc5daf95df2-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 1E0003A19CB for ; Fri, 2 Apr 2021 08:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 EqYUuxB7nclT for ; Fri, 2 Apr 2021 08:10:39 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CD93A19CE for ; Fri, 2 Apr 2021 08:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617376238; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=fNAuJ/VbsFEVMrn/tyxdyNvkq5Cco+1qvz3epWibdGg=; b=a/6OSdjssmcY+piD3yRCKON72yEONo5Nbw6CJWYLIDwQ+W1hepYkomyTuS66iKr3 Xf9hVhgfAfLhHXbvTF4DAEcnRa/bH9fu4HepTyK0N7/cvHboEtv3scA2yEauwovUbmO UUZyFe/UwoiB4cmjPoMH/NUUJBnFzel8G38AQCaE= From: Kent Watsen Message-ID: <010001789322da54-a43f6e89-c6a6-4653-a878-1bc5daf95df2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_87FF4C02-020E-4616-94C5-B231CAA6ED3B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 2 Apr 2021 15:10:38 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: "Carey, Timothy (Nokia - US)" References: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.02-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] draft-ietf-netconf-trust-anchors: Open issue in github X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 15:10:41 -0000 --Apple-Mail=_87FF4C02-020E-4616-94C5-B231CAA6ED3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tim, > I was looking at the open issue for the = draft-ietf-netconf-trust-anchors-14 in git hub -Missing prefixes in = typedefs certificate-ref and public-key-ref = (https://github.com/netconf-wg/trust-anchors/issues/1 = ) that resolves a = YANG lint error. > =20 > I have seen this issue fixed, is this possible to resolve in the next = draft version? Yes, I just pushed this commit: = https://github.com/netconf-wg/trust-anchors/commit/6de9096bab22e005ba5f19f= 52a636385c18a8b2e And related commit in keystore: = https://github.com/netconf-wg/keystore/commit/ba8da8ed2e8c7a45f4ec5c3abac9= 33edc478eff7 Cheers, Kent --Apple-Mail=_87FF4C02-020E-4616-94C5-B231CAA6ED3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Tim,

I was looking at the open issue for the = draft-ietf-netconf-trust-anchors-14 in git hub -Missing prefixes in = typedefs certificate-ref and public-key-ref (https://github.com/netconf-wg/trust-anchors/issues/1) = that resolves a YANG lint error.
 
I have seen this issue fixed, is this possible = to resolve in the next draft version?


Yes, I just pushed this = commit:


And = related commit in keystore:


Cheers,
Kent

= --Apple-Mail=_87FF4C02-020E-4616-94C5-B231CAA6ED3B-- From nobody Fri Apr 2 08:14:43 2021 Return-Path: <01000178932683b3-f9a114b8-b525-479e-b7f2-ff8300b32d14-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 C15583A19F0 for ; Fri, 2 Apr 2021 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 y_AAbnsD23rr for ; Fri, 2 Apr 2021 08:14:39 -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 9DEEC3A19EA for ; Fri, 2 Apr 2021 08:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617376478; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=wUN6oDO+CqfCaLb8Zgq5jTv7pPlQzPlSkOFsT0wzYEo=; b=NGX3bdE40uB+sxIZ7bZDC2Zz9PNlIqq4uVP/CSXr4ylkrvfhmg4Y3Yj0zfBNOhCU nKW8RG+Rqi6QAaCot2mC12FIkNzLKf1kHJVwvdL3dHYMXNko3b+LzGBYcIv2OqCJgvi Lh+nQD9ZaJByfW6Hvi+SrQkokd7ewYomsVPLHxwM= From: Kent Watsen Message-ID: <01000178932683b3-f9a114b8-b525-479e-b7f2-ff8300b32d14-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_74BBF355-EE42-44D2-89D0-178E71C4B6C4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Fri, 2 Apr 2021 15:14:38 +0000 In-Reply-To: Cc: Juergen Schoenwaelder , RFC Errata System , Balazs Lengyel , "andy@yumaworks.com" , "mbj@tail-f.com" , "warren@kumari.net" , Mahesh Jethanandani , "netconf@ietf.org" To: "Rob Wilton (rwilton)" References: <20210324151954.6A2C2F40739@rfc-editor.org> <20210324155608.upn2zjjutgobgtqa@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.02-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8341 (6493) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 15:14:41 -0000 --Apple-Mail=_74BBF355-EE42-44D2-89D0-178E71C4B6C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I agree with Juergen that section 9.13.2 of RFC 7950 applies and hence = my opinion is that this errata, against RFC 8341, should be rejected. +1 (as contributor) > However, I also think that RFC 7950 isn't as clear as it should be. = Given that there is an explicit ABNF construct for instance-identifier, = I really think that this ABNF should explicitly require prefixes for = node-identifiers, avoiding any potential ambiguity in what is allowed. Should a YANG-next issue be filed? K. --Apple-Mail=_74BBF355-EE42-44D2-89D0-178E71C4B6C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I agree with Juergen that section 9.13.2 of RFC 7950 applies = and hence my opinion is that this errata, against RFC 8341, should be = rejected.

+1 (as = contributor)


However, I also think that RFC = 7950 isn't as clear as it should be.  Given that there is an = explicit ABNF construct for instance-identifier, I really think that = this ABNF should explicitly require prefixes for node-identifiers, = avoiding any potential ambiguity in what is allowed.

Should = a YANG-next issue be filed?


K.

= --Apple-Mail=_74BBF355-EE42-44D2-89D0-178E71C4B6C4-- From nobody Fri Apr 2 08:57:11 2021 Return-Path: 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 AA9DF3A1B1B for ; Fri, 2 Apr 2021 08:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 e2Z2dohRY7-b for ; Fri, 2 Apr 2021 08:57:04 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C645E3A1B18 for ; Fri, 2 Apr 2021 08:57:03 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id u4so6027903ljo.6 for ; Fri, 02 Apr 2021 08:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WHZDRBMajNsItXn6WvqN4VymEag4oHy27Qxiu3r8160=; b=1+X7uUTQgEETFEQZkEYfZEzKyjaD03NWGKm9qlWPh6sdEEw6EWDMk6yE5mRdo9FTUz 9BcoAqdSTXRy6n/cT7kDWt+eZiYgji0fbqdl5AJLsErcfz0KjNeQrlEQo94ox6CEelfp pCCBdrGODcY6VschfvvpvkNEbDmv+cfq3MloZT73HsEuoEFE6ewW5fzmtrUfZqliZ88G KHJh+OG3KFjwj93rvhnGYdkm79LmqUnN2Jc7kZWEF33QyAm8fMNVegF4W5Tq95ygcWwX AwH4sb4XUkGUjcRKpBzZSeWEJG6QDYoi2nDy4fEyQXeGon5uKxul9ATshdkK4ZkXNQcY wx6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WHZDRBMajNsItXn6WvqN4VymEag4oHy27Qxiu3r8160=; b=OepLR4+luGrOlds09potZv0753z6JVcAUwNnd1mXPaIJbpKc1zNbHomauLFa8M/z/2 xd8afpiF2tUmO8ONzgEjJOacYuFH1NzgVpj8HBcy8giLHL00pFXttUfpR67mP5Xv9opn zLrZHu/lWmcWQcqof0yjicYD6d8UQMfhnlrL11z+h8M7L95pO/jY8Lk53MgN++SxiEeM YICDKWd7euxq1/YShtKylM1J1LdfKluuUQB5XjlS7ZpracUbaeq9O/rLn4RT2vJF6hx3 xPTVxz9zE9O1Zrp6TaBR1eixwLkdHjwRX7VlBMVEejXpwOZelmKed1iG4iSv3SIxJEOB hNOw== X-Gm-Message-State: AOAM533TYMHjjlLCATibPbLII/ircozNTgcOMQXOQ35LkHNKY09Y5DcQ +KAoju/Zu6mt7ydjSyPo31HFkN9kH7iCayJAYZKedA== X-Google-Smtp-Source: ABdhPJwKJNTGX52odMzBVT5SnzsdirW0Ca4edU5oQZiuz29lLfhmdaH3oJrCar0dxVtwmyS/Q/yspzV0iH73/uEDCNk= X-Received: by 2002:a2e:9157:: with SMTP id q23mr9042112ljg.298.1617379020329; Fri, 02 Apr 2021 08:57:00 -0700 (PDT) MIME-Version: 1.0 References: <20210324151954.6A2C2F40739@rfc-editor.org> <20210324155608.upn2zjjutgobgtqa@anna.jacobs.jacobs-university.de> <01000178932683b3-f9a114b8-b525-479e-b7f2-ff8300b32d14-000000@email.amazonses.com> In-Reply-To: <01000178932683b3-f9a114b8-b525-479e-b7f2-ff8300b32d14-000000@email.amazonses.com> From: Andy Bierman Date: Fri, 2 Apr 2021 08:56:49 -0700 Message-ID: To: Kent Watsen Cc: "Rob Wilton (rwilton)" , Juergen Schoenwaelder , RFC Errata System , Balazs Lengyel , "mbj@tail-f.com" , "warren@kumari.net" , Mahesh Jethanandani , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f9693f05beff65cc" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8341 (6493) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 15:57:09 -0000 --000000000000f9693f05beff65cc Content-Type: text/plain; charset="UTF-8" On Fri, Apr 2, 2021 at 8:14 AM Kent Watsen wrote: > > I agree with Juergen that section 9.13.2 of RFC 7950 applies and hence my > opinion is that this errata, against RFC 8341, should be rejected. > > > +1 (as contributor) > > > However, I also think that RFC 7950 isn't as clear as it should be. Given > that there is an explicit ABNF construct for instance-identifier, I really > think that this ABNF should explicitly require prefixes for > node-identifiers, avoiding any potential ambiguity in what is allowed. > > > Should a YANG-next issue be filed? > We could think a bit about the real problems with instance-identifier instead of academic discussions. The ABNF only describes the syntax of the default-stmt representation of an instance-identifier. Since such a default would be extremely rare, this is not an interesting problem. The RFC is clear that prefixes are required. The protocol message (or artifact) representation of an instance-identifier is a much more relevant use-case. XML has its own rules for binding namespaces to QNames in the context of an XML instance document. These rules are clear, so no problem to be solved here. The real problem (for yang-next?) is that the instance-identifier and identityref data types do not have any context-free representation possible, let alone a canonical representation. The solution already exists in RFC 7951 (6.8 and 6.11). These encoding rules for identityref and instance-identifier should be used for all representations, and the default-stmt, The XML and YANG encodings should be replaced (by introducing new types and deprecating the old ones). > > K. > > Andy --000000000000f9693f05beff65cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable









K.


Andy
=C2=A0
--000000000000f9693f05beff65cc-- From nobody Fri Apr 2 09:11:47 2021 Return-Path: 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 CB8253A1BB2 for ; Fri, 2 Apr 2021 09:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=nokia.onmicrosoft.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 yQ-iezJ82jpx for ; Fri, 2 Apr 2021 09:11:40 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2129.outbound.protection.outlook.com [40.107.223.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10143A1BB1 for ; Fri, 2 Apr 2021 09:11:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SB5NJp+8/i7A3XAuJDIPZc93i58Kx61g1cZWon+UqQi2ziJAq2Zy8UQbdO2xrPKEqEtPe7Jmpf1di2GipWvp/kkU1mm1rXwUQfyyIBa10AfIH6iTvS1b/GZ3MCyvyRHZdu1b071TSCnf2JlT6O1KdRblNAhVLk5Iz53gxE7v/vYsPHWu6pzxe/Nn1fzU1khZ1lNuVAwtANKIGgkrQujh95z3S7IIPB0yLFU2SXWRmHRovkWrbSbkCzOhoDHDAgwC4/IXJydy/d2eocoQLvuLV/V0oN4BDwjjvq2SK4CliS/JBFgM/oPdnu0yEHj2WsapK4NqMt4/NJCVMfL92iW+dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JI4FFb1fqJc0czXSpnxDKS+xmOPRbNqsvbtgpLHxaOg=; b=GynnZ3uR8NhzmLqbvSCbF0NOOejFKx6vghwPuYp2erhd+HliENwbuEKu7Uyzda8YyXxytaaF6wkcWLZ/dXfS8uwhwmgdMSSBWhiwJloIoRllpJgIACRBSxzN2MzsOCC5rgYY0SaH8+syoRqNCH5mM4sDHMRNwNaVCPdC/X0HGpHGKTKCck+G74Z94vdwqSdYGPhnKMZQT9GXn9cRXZBPD1wrRQumEplsWuFkeS84abQgyEjqcaN5f/vP5urxrQxKbpkShd10K4vd4NSdDlpqGcqZkr1KwgsNDnm9AiCUwanOrrJKecv8H4zXhAnFi1lm84o4hxzT1W/AtVF/SjJGOg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JI4FFb1fqJc0czXSpnxDKS+xmOPRbNqsvbtgpLHxaOg=; b=JpFsuZKEHL+TVq2eowMqIicfytrWt6+0kJ/DVfl+yybj3T4nxlkcZg65Bv24CIlAJ69x7pzHIXm/llBoWS7v2YbSAgkvpGBhnzRaB7PCEsqEKZXCw177yy1mtLnjenfbmsRbTYxsPd01QAZL4ZwbbiHuN2MdCyhscmGkh21iVQQ= Received: from SN6PR08MB4208.namprd08.prod.outlook.com (2603:10b6:805:3b::21) by SN6PR08MB4751.namprd08.prod.outlook.com (2603:10b6:805:76::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.32; Fri, 2 Apr 2021 16:11:37 +0000 Received: from SN6PR08MB4208.namprd08.prod.outlook.com ([fe80::b4d9:1eec:aaa5:2dd8]) by SN6PR08MB4208.namprd08.prod.outlook.com ([fe80::b4d9:1eec:aaa5:2dd8%2]) with mapi id 15.20.3999.029; Fri, 2 Apr 2021 16:11:37 +0000 From: "Carey, Timothy (Nokia - US)" To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] draft-ietf-netconf-trust-anchors: Open issue in github Thread-Index: AdcmIV5Qez65x+vdTXuXZ+fjj+pOLwBsPhEAAAIZc4A= Date: Fri, 2 Apr 2021 16:11:37 +0000 Message-ID: References: <010001789322da54-a43f6e89-c6a6-4653-a878-1bc5daf95df2-000000@email.amazonses.com> In-Reply-To: <010001789322da54-a43f6e89-c6a6-4653-a878-1bc5daf95df2-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=nokia.com; x-originating-ip: [24.155.49.224] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 527a7e2e-6a1e-421a-cbe0-08d8f5f1fe6b x-ms-traffictypediagnostic: SN6PR08MB4751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:549; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BB5tKVUE99cRD82pqUQKMKNGxwjGKg8Wc9LA0vqVQdvfhe5dJDhWKV12FnvCOzLgohhzhYchlRL2Z/Crj7lV3lE+Dg1zEC17wvnh0pkGAELqOVdQ+y1xpI3Xwl/2c0Ggedv4r93Iuemwk259Aoc7oZEgGphl2cJLnXqTvYT8dWFzEc2eQ/TCijWBviNSolBPCSquSp/S4ayhZIkPbahdcCBOIQjno29X1P93hvIFIF5MiBmeENPs1k0sPRDA3h4pnE9yhMHoJRerwzpcAnVbWlhi6CLg9j1pgnK1bfw/3VuN9XTUz4P/4U142YzXAFsUjToVPdZHvTnoT+hXFpmLK/etGBhBmiOuBeK8FLmKt4UPoSVahhjJn3rfRxkH0eimIWVtC7ZNRJkd2SdHezhW/8xZY+3UD9KieMiK6IOZAai+D6DGIKHFge/c9sPfVyAoXlmkODa5OfvfYSQpoX95Jvk6cPjAMStiPNOZswxnBP/aSF3BkG8DNKgpoFG2PuBBNUStLaWEcMGmbOkJAk0twSGvifUqV1YtF3jAKw0nfyGNht2+oGlO0FaH3wEIRJG1ifzv8ZDlGhLKVMM6pWC91tICqYEjjQo+u6Z0qeac2zqn5RW2rHLRb+mh6TNgVXlg/Wh9/7A+fYge0swCkPgBWJbddd4dDzLNtptRaV///Zd451rLVziF2vnr690bGbxtDW8aaVk6D0cAc2VZGK73rL8ySYHAGONtqts0e56blHQ/utwMDtS2QmM1Il1REdSZ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR08MB4208.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(39860400002)(136003)(366004)(478600001)(6506007)(2906002)(966005)(33656002)(71200400001)(4326008)(5660300002)(86362001)(26005)(4744005)(66446008)(6916009)(8936002)(8676002)(55016002)(9686003)(316002)(38100700001)(186003)(53546011)(52536014)(76116006)(166002)(66556008)(66476007)(66946007)(7696005)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?aUwzq+ZwtcZ9nZ8t3rzXgdaqpizotRSl6hmJ8uaoJCrDHJ63S52rZyEaD8PG?= =?us-ascii?Q?rLen3vu4+p8gRfJiFVG7c58p/eHx9wYxe237X0x4Tpe0FBzXynp/fLAUm/VX?= =?us-ascii?Q?kIC8lJMApXRGT05tGsm9vHzF2sD/ul/64gGyz76aAt0yMl1yVPgvDYiT0YQl?= =?us-ascii?Q?DLIFo9fTXUT52GFNfcaB/7k/9K7k2mOQs3rKYSCdYx/Ynog6gO1pJoEHCMEB?= =?us-ascii?Q?hPLA4imn/Ap1n2bQ3ZGkfOUwUWk2U2mQX/gizIMcLTZiiRGdhkpbzESTBfUw?= =?us-ascii?Q?qUHrGejmVhTFp99Ck8jYMXV+nQpG+IoWrxj06Hgdb02k8l1gGxLs0xnRAUnb?= =?us-ascii?Q?VPjXI5ZA//spJ0PJBZpA5aDfwg6BLsqNHNiA9uVZgULusGQqM2gbSgipcnmp?= =?us-ascii?Q?3NBChhtNtbPQZ4i7oB6NcfyIL+PPRrb4ELf3HAj9DYC12hrIdMLvKWjq+kyV?= =?us-ascii?Q?7bycJN9OlpcnR8LO+zMhmTpe5CybfCbu+UN2bcVyVrVUyMUfi0rwgo//5O/p?= =?us-ascii?Q?7sVVvDklShO+NHnEIZA4Ynf3MsKhwdMweV288wgg69nUI+kDFB2qw56mXM2g?= =?us-ascii?Q?4bj6Qc/SmYPeAbC/ss9Znm9NnSHwjPoA46ldBE6JUTXo3uny2pYuXbKA1kkU?= =?us-ascii?Q?mMdiOTfOzCapfGlMYzikebI7UnrXpbBWJZtWGvFKnifa6T6TfJfHyZpDQ/BI?= =?us-ascii?Q?53IFo6CClKQrQMKtyDNsNcPQYwbu1Xg+FDYI8S0zKlhAc+aKzB6I5YQ9hJgW?= =?us-ascii?Q?H095l3S6a42RDnOmGpFUOO9ZJ+QDHz+hfDn4FF5LqBNyFAvloYGC4b7uiuqi?= =?us-ascii?Q?OdUjwQNut+U6EdVcZWzxJhrDdVbiZZBNiQWLElA6eBKt9NVMASYg+PARQV3M?= =?us-ascii?Q?AIf+7W113t9GojUbw61IvtQ4nX0Miw4Hck9flHngQ/qnztklUSjTFo7gAVOv?= =?us-ascii?Q?zQmJzKjX9iBjsESgA2u1wrJ98foe+yDdFjNLEEBzVVZMe+vofm+ZWAsbEUhk?= =?us-ascii?Q?19+oO9lDsFXV02PiZ40ocLodeRp2Ldhhol12fuKGL/F1GjFpMVGggGaIFCY8?= =?us-ascii?Q?tC5fm2PfdHcao5cRbx7l50O25KUyCO7zwm2ldw4xi6CvU3nviA9wiD6kH0UR?= =?us-ascii?Q?RshGWqa+vyjJ4SatYBE4GdAj9lKyuQvZly2/jIlB0q+/42T+EwXYpjoin8t8?= =?us-ascii?Q?KQNgAs0FnfSPtdF7QcRP6nlnR2xze/5hfkID+yRrm8OTTg/O6O59JKzUA1IL?= =?us-ascii?Q?0xyEasbR1qP4tiuClrn4gUBpWLRX8PTFwy1LR86QbvTYlDiwVZ8FQwGZVO3B?= =?us-ascii?Q?Bx9s9fsZpGJLDXZOIr15Krov?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR08MB4208EA6CC2F6010F265D4789EF7A9SN6PR08MB4208namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR08MB4208.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 527a7e2e-6a1e-421a-cbe0-08d8f5f1fe6b X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2021 16:11:37.6186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AfA8tZmji/i8D8pju3tfjKpLjCsbZFFUBJSZNf1zuZspbsceEPU773PJOMjh0VBJ8T50jfzGoei6BW9HGiw1JA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR08MB4751 Archived-At: Subject: Re: [netconf] draft-ietf-netconf-trust-anchors: Open issue in github X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 16:11:45 -0000 --_000_SN6PR08MB4208EA6CC2F6010F265D4789EF7A9SN6PR08MB4208namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Kent - I appreciate that. From: Kent Watsen Sent: Friday, April 2, 2021 10:11 AM To: Carey, Timothy (Nokia - US) Cc: netconf@ietf.org Subject: Re: [netconf] draft-ietf-netconf-trust-anchors: Open issue in gith= ub Hi Tim, I was looking at the open issue for the draft-ietf-netconf-trust-anchors-14= in git hub -Missing prefixes in typedefs certificate-ref and public-key-re= f (https://github.com/netconf-wg/trust-anchors/issues/1) that resolves a YA= NG lint error. I have seen this issue fixed, is this possible to resolve in the next draft= version? Yes, I just pushed this commit: https://github.com/netconf-wg/trust-anchors/commit/6de9096bab22e005ba5f= 19f52a636385c18a8b2e And related commit in keystore: https://github.com/netconf-wg/keystore/commit/ba8da8ed2e8c7a45f4ec5c3ab= ac933edc478eff7 Cheers, Kent --_000_SN6PR08MB4208EA6CC2F6010F265D4789EF7A9SN6PR08MB4208namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Kent – I appreciate that.

 

From: Kent Watsen <kent@watsen.net> Sent: Friday, April 2, 2021 10:11 AM
To: Carey, Timothy (Nokia - US) <timothy.carey@nokia.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] draft-ietf-netconf-trust-anchors: Open issue = in github

 

Hi Tim,

 
--_000_SN6PR08MB4208EA6CC2F6010F265D4789EF7A9SN6PR08MB4208namp_-- From nobody Fri Apr 2 12:33:33 2021 Return-Path: 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 4A2683A2112 for ; Fri, 2 Apr 2021 12:33:26 -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 tgI7EkaLPYad for ; Fri, 2 Apr 2021 12:33:21 -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 403213A20F2 for ; Fri, 2 Apr 2021 12:33:18 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id C4C3160088; Fri, 2 Apr 2021 21:33:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1617391987; bh=77Tfvzv1IlpXQHs2oHAEwC4bfT18ZeOIm/0QvNyUd/I=; h=From:In-Reply-To:Date:Cc:To:Subject; b=AM2G9QibEzcoVYxY4vRQVSqa+IUTpMEMYtcwPRg4nJ4NzRh8PFTeFAHKS0+wmlxzB zUZItsQFtNPqbgOgIgY0EvO5qjui6Muv9Nped6YsS/9FsFpXBHH5nhl0JTmLgydd87 A2z+6CbaZFrEfPHlZd2Q8gLsxuBf/NFsFpVRodHg= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <0100017804af516b-fff3cc4f-3806-4108-a448-db4249a437a4-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Fri, 02 Apr 2021 21:33:07 +0200 Cc: "netconf@ietf.org" To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <5303-60677180-31-62233d80@261934540> User-Agent: SOGoMail 5.0.1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 19:33:32 -0000 Hi Kent, firstly I am sorry, somehow I missed this reply, my bad :( > > I had a chance to look at these modules again and have 2 questions = regarding some recent changes. > > > > - ietf-ssh-server, ssh-server-grouping/client-authentication/suppor= ted-authentication-methods> > > Since the "other" leaf-list was removed there is no way to support = some other methods than those specified. I am not sure whether this was= the intention and if so, what is the reason for it? If nothing else, w= e support "interactive" authentication method but there are some others= that I see no reason why they could not be used. > > It took me a bit to determine that this change happened in ssh-client= -server-18. > > The motivation behind the change was to align the values with those d= efined in RFCs 4252 and 4250. > > You mention an =E2=80=9Cinteractive=E2=80=9D and =E2=80=9Csome other=E2= =80=9D methods - where are they defined? That is a good question. It seems no other methods are standardized but= that does not mean they are not used. > > For a robust and extendible solution, why not use an identityref le= af-list with all the methods as identities? One could then simply add n= ew ones with specific "if-feature" statements. > > An identityref seems reasonable, could you propose a snippet of YANG = for it? > > That said, it seems equally possible for a future module to augment-i= n a new leaf under the "supported-authentication-methods=E2=80=9D conta= iner... Right, that would solve the problem, too. So you can keep it the way it= is, up to you which solution you prefer. Not sure why I did not think = of augments first but identityrefs. But identityrefs are much more gene= ral so the implementation should probably depend on whether these authe= ntication methods are to be used only for this single purpose or not. > > - ietf-netconf-server, grouping netconf-server-grouping/client-iden= tity-mappings > > > > The "if-feature" on this container is strange. The practical proble= m is that if one wants to support certificates only for TLS, both one o= f the TLS features and "ssh-x509-certs" must be enabled. This then resu= lts in the container being defined for both SSH and TLS so there is no = way to support it only for TLS or SSH. > > Yes, granular features would be nice. This issue is tracked here: ht= tps://github.com/netmod-wg/yang-next/issues/82 . A possible fix would be to enable features= on a per-XPath basis, perhaps using the =E2=80=9Cnode-tags=E2=80=9D dr= aft going on in NETMOD. Do you have a proposal? > > BTW, shouldn=E2=80=99t the =E2=80=9Cif-feature=E2=80=9D statement hav= e an =E2=80=9Cor=E2=80=9D (not an =E2=80=9Cand=E2=80=9D) between the tw= o major expressions? Yes, I think "or" fits much better. I just was not sure whether there i= s not a specific reason why "and" was chosen. Regards, Michal From nobody Fri Apr 2 12:49:36 2021 Return-Path: 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 395C53A2141; Fri, 2 Apr 2021 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 qrf9f33TK5Gg; Fri, 2 Apr 2021 12:49:30 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee: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 0750A3A213C; Fri, 2 Apr 2021 12:49:29 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 18C2A60088; Fri, 2 Apr 2021 21:49:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1617392965; bh=9oemDNenWsWvOamzYnrH4Sl9xT/sqxZ5MLVCZhKvIow=; h=From:In-Reply-To:Date:Cc:To:Subject; b=03UPHwVBvU4VoXQlWgTAUsGfukckahcotd4/gwARcFbCfVeAf2g02djViYHN/HAxj KS8xIMmF9yJ0wx5FgQslZPl7RnZH6QFsHN7Xq/RhuaseHR2rYFFRezpnqwuarZZofY XBuqy2DyVJONvXSO32zlPiNMZRh9GWRXHAfoGCxs= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Fri, 02 Apr 2021 21:49:25 +0200 Cc: "netconf" , "netmod" To: "Eric Voit (evoit)" MIME-Version: 1.0 Message-ID: <5830-60677580-9-1569b540@260964559> User-Agent: SOGoMail 5.0.1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?YANG_Push_module_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 19:49:35 -0000 Hi Eric, thanks for the answer. On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" wrote: > Hi Michal, > > This sounds like a tooling issue to me. I would expect that any augm= ents > would inherit the conditional nature of anything augmented. Perhaps, but there is nothing in the specification to hint this. On the= contrary, leafrefs, for example, explicitly require to be conditional = on the same set of if-features than their targets. But you are right, t= here is no such requirements for augments. Still, if the feature is dis= abled and the augment should be applied, since its target does not tech= nically exist in the schema, it cannot be found. That is the error our = tools currently produce. > If you disagree, perhaps a thread to the netmod alias would get you a= n > 'official' answer on the proper behavior. I have sent the email to "netconf" because that is WG that published it= but no harm in adding a copy for "netmod". > Eric > > > -----Original Message----- > > From: netconf On Behalf Of Michal Va=C5=A1= ko > > Sent: Thursday, April 1, 2021 11:14 AM > > To: netconf > > Subject: [netconf] YANG Push module errors > > > > Hi, > > > > we are led to believe there is an error in the ietf-yang-push modul= e > published in > > RFC 8641 but I wanted to discuss it here before submitting an errat= a. > There are 2 > > augments [1] on a notification that is conditional on "configured" = feature > but > > these 2 augments are not conditional. Having this feature disabled,= we > were not > > able to load this module into our tools. Does anyone disagree with = this or > with > > submitting an errata? > > > > Regards, > > Michal > > > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Apr 2 12:58:55 2021 Return-Path: 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 043A53A2171 for ; Fri, 2 Apr 2021 12:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pEAlQSwlg7iS for ; Fri, 2 Apr 2021 12:58:49 -0700 (PDT) Received: from 3.mo52.mail-out.ovh.net (3.mo52.mail-out.ovh.net [178.33.254.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494263A216F for ; Fri, 2 Apr 2021 12:58:48 -0700 (PDT) Received: from mxplan1.mail.ovh.net (unknown [10.109.146.249]) by mo52.mail-out.ovh.net (Postfix) with ESMTPS id 7BB52256410; Fri, 2 Apr 2021 21:58:45 +0200 (CEST) Received: from claise.be (37.59.142.104) by DAG7EX1.mxp1.local (172.16.2.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Fri, 2 Apr 2021 21:58:44 +0200 Authentication-Results: garm.ovh; auth=pass (GARM-104R00595f38959-a016-4277-b85c-65598ad2e5e6, 3B2CF43F0847030AB951E048FB9C32EE0DD6F736) smtp.auth=benoit@claise.be X-OVh-ClientIp: 109.89.184.41 To: Kent Watsen , Benoit CC: "netconf@ietf.org" References: <0100017179dc6961-166c9a34-ed06-4e26-9240-83728a433691-000000@email.amazonses.com> <01000178055cadf0-27b0cd28-e8f1-489d-bf16-d99367461a5c-000000@email.amazonses.com> From: Benoit Message-ID: Date: Fri, 2 Apr 2021 21:58:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <01000178055cadf0-27b0cd28-e8f1-489d-bf16-d99367461a5c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="------------472DA84163887128C9007B07" Content-Language: en-US X-Originating-IP: [37.59.142.104] X-ClientProxiedBy: DAG5EX2.mxp1.local (172.16.2.10) To DAG7EX1.mxp1.local (172.16.2.13) X-Ovh-Tracer-GUID: 6697fb73-a255-4df2-a45d-7d2eafb532ea X-Ovh-Tracer-Id: 8607786264189421533 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrudeiiedgudegvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefjeenucfhrhhomhepuegvnhhoihhtuceosggvnhhoihhtsegtlhgrihhsvgdrsggvqeenucggtffrrghtthgvrhhnpeduheejgfdvheeftdefhfeuhfeiveeghfevgfduieeuffettedutdelgfegheekgeenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddruddtgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehmgihplhgrnhdurdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepsggvnhhoihhtsegtlhgrihhsvgdrsggvpdhrtghpthhtohepsggvnhhoihhtsegtlhgrihhsvgdrsggv Archived-At: Subject: Re: [netconf] Shepherd review of draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 19:58:54 -0000 --------------472DA84163887128C9007B07 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Removed what's agreed upon. See inline. > Balazs and Benoit, > > Thanks for the update and the response.  Please see below for followups. > > K.  // shepherd > > >> On Feb 22, 2021, at 4:20 PM, Benoit > > wrote: >> >> Hi Kent, >> >> Sorry it took us so long to update the draft. >> Below are our answer. We believe we have addressed all comments. > > >> - s/YANG Instance Data/YANG Instance Data >> (I-D.ietf-netmod-yang-instance-file-format)/ >> BALAZS: OK > > Hmmm, now it’s renamed and moved to the end of the paragraph, but > still without a reference.  Admittedly, I think references in > Abstracts are discouraged but, as it stands, readers may be confused. >  Note that searching for "YANG Instance Data File Format” doesn’t > resolve any other matching because only other matching string is in > the “Normative References” Section, where it line wraps.  If you don’t > put a reference into the abstract, then import the term in the > “Terminology” Section. Done. Added to the terminology section:           The terms "YANG instance data file format", "instance data", and             "instance data set" are used as defined in           . > > >> - s/"Subscription to YANG Datastores" (YANG-Push)/Subscription >> to YANG Notifications for Datastore Updates (RFC 8641)/ >> BALAZS: OK > > Thanks, but not that the sentence ends 'augmenting the > "ietf-system-capabilities”.’   This should either be 'augmenting > "ietf-system-capabilities”.’ or 'augmenting the > "ietf-system-capabilities” module.' > > Done. 'augmenting "ietf-system-capabilities” >> - Actually (in ref to the above two comments), the sentence structure >> in p2 seems >> backwards. Better would be to say "The module can be used to report >> capability >> information from the server at run-time or implementation-time, per >> I-D.ietf-netmod-yang-instance-file-format.” >> BENOIT: idnits complains when we have references in the abstract. >> Removed the references > > Ah, yes, right, then import the term? See above. Added to the terminology section: > >> - s/that can be used to specify/that can be used to discover (as >> read-only operational state)/ >> BENOIT: DONE > > Good, but searching for "hat can be used to specify” resulted in > finding two other instances that I believe would benefit from the same > update. Only one was left, in the abstract. Now changed. Note that I did not add "(as read-only operational state)" in the abstract. I left for the explanation in the draft. I'm fear that might be distracting and confusing. > > >> - rather than have the “description” statement "// augmentation >> point for system level capabilities”, why not have an empty >> “choice” statement with the same description statement? >> BALAZS: choice would not be a good solution because it would only >> allow one set of capabilities, while our goal is to allow different >> capability set side by side. > > You misunderstand.  Adding an empty choice preserves the data model as > is.  It’s just a more "YANG way” to do what you have: > > OLD: >     // augmentation point for system level capabilities > > NEW: >    choice system-capabilities { >       // mandatory true;  // must at least one exist? >       description >          "augmentation point for system level capabilities.”; >    } > In our opinion,  the choice is not an ideal solution. For the choice you may only select one case. We, on the other hand, want to allow multiple augmentations to be used at the same time. If we used a choice, we could not allow multiple different cases/augmentations to be used at the same time. It is a question of on-of-many versus any-number. > > >> - rather than have the “description” statement "// augmentation >> augmentation point for datastore or data node level capabilities”, >> why not have an empty “choice” statement with the same >> description statement? >> BALAZS: see above. > > Also see above  ;) Also see above ;) > > >> - is the comment "The special value '/' denotes all data nodes in the >> datastore.” should state if it’s a CLR or simply consistent with >> XPath 1.0 expressions. >> BALAZS: we are consistent witjh the NACM RFC, which says: >>                     The special value '/' refers to all possible >>                     datastore contents."; > > Then the comment should say “As specified in NACM Section ???, the > special value…”, right? Done.           leaf node-selector {             type nacm:node-instance-identifier;             description               "Selects the data nodes for which capabilities are                specified. The special value '/' denotes all data nodes                in the datastore, as specified in path YANG object in                data definition statement [RFC8341];             reference                   "RFC 8341: Network Configuration Access Control Model";           } > > >> - this command detected an issue: pyang --ietf >> ietf-system-capabilities\@2020-03-23.yang. >> (I’m unsure why, exactly, as I see the keywords block in the module $ pyang --ietf ietf-system-capabilities.yang $ $ pyang -v pyang 2.4.0 >> …suggest copying >> text directly from `pyang --ietf-help`. > > No response? That was an oversight. Done. > > > >> - this command detected a number of issues: pyang -f yang >> --keep-comments --yang-line-length 69 >> ietf-notification-capabilities\@2020-03-23.yang > tmp; diff >> ietf-notification-capabilities\@2020-03-23.yang tmp. (whitespace at >> end of lines) > > No response? That was an oversight. Done for both modules > > > > > >> - through draft (in both body and YANG modules), bracket datastore >> names with >> angle brackets (e.g., s/running//) wherever the datastore >> name is NOT >> followed by word “datastore”. When the datastore name is NOT followed >> by the >> word “datastore", the datastore name should be in quotes, where it >> makes sense >> to do so. BTW, I note the none of the datastore names are imported as >> terms or >> otherwise introduced where first used... >> Benoit: Done > > I don’t see these changes... What I did in the previous draft version: I searched for all instances of running, and it's always followed by the word datastore. I did the same for candidate, operational (there are no instances of startup and intended). I double-checked this new version too. Added a reference to RFC 8342 with the first occurrence of datastore in the intro. > > >> - the YANG Doctor review suggested adding comments regarding >> if imports needed to be implemented. I see such comments were >> added in -06 but they’ve subsequently been removed. I strongly >> second Lada’s suggestion to include a minimal YANG Library >> instance somewhere, not only to document which modules need to be >> implemented, but also to document the totality of them, as I >> was unpleasantly surprised by how many there were (12 in total!) >> BALAZS: OK, Included for the 3 imports that need implemented. They >> were removed due to comments, but I like the sentences. > > Better, but no YANG Library instance?  Oh well. Thanks for your review. I'll be posting a new version soon. Regards, Balazs and Benoit > > > K. > > --------------472DA84163887128C9007B07 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Kent,

Removed what's agreed upon.
See inline.

Balazs and Benoit,

Thanks for the update and the response.  Please see below for followups.

K.  // shepherd


On Feb 22, 2021, at 4:20 PM, Benoit <benoit@claise.be> wrote:

Hi Kent,

Sorry it took us so long to update the draft.
Below are our answer. We believe we have addressed all comments.


- s/YANG Instance Data/YANG Instance Data (I-D.ietf-netmod-yang-instance-file-format)/
BALAZS: OK

Hmmm, now it’s renamed and moved to the end of the paragraph, but still without a reference.  Admittedly, I think references in Abstracts are discouraged but, as it stands, readers may be confused.  Note that searching for "YANG Instance Data File Format” doesn’t resolve any other matching because only other matching string is in the “Normative References” Section, where it line wraps.  If you don’t put a reference into the abstract, then import the term in the “Terminology” Section.
Done.
Added to the terminology section:
          The terms "YANG instance data file format", "instance data", and
            "instance data set" are used as defined in
          <xref target="I-D.ietf-netmod-yang-instance-file-format"/>.


- s/"Subscription to YANG Datastores" (YANG-Push)/Subscription
to YANG Notifications for Datastore Updates (RFC 8641)/
BALAZS: OK

Thanks, but not that the sentence ends 'augmenting the "ietf-system-capabilities”.’   This should either be 'augmenting "ietf-system-capabilities”.’ or 'augmenting the "ietf-system-capabilities” module.'


Done. 'augmenting "ietf-system-capabilities”
- Actually (in ref to the above two comments), the sentence structure in p2 seems
backwards. Better would be to say "The module can be used to report capability
information from the server at run-time or implementation-time, per I-D.ietf-netmod-yang-instance-file-format.”
BENOIT: idnits complains when we have references in the abstract. Removed the references

Ah, yes, right, then import the term?

See above. Added to the terminology section:

- s/that can be used to specify/that can be used to discover (as read-only operational state)/
BENOIT: DONE

Good, but searching for "hat can be used to specify” resulted in finding two other instances that I believe would benefit from the same update.
Only one was left, in the abstract. Now changed.
Note that I did not add "(as read-only operational state)" in the abstract. I left for the explanation in the draft. I'm fear that might be distracting and confusing.


- rather than have the “description” statement "// augmentation
point for system level capabilities”, why not have an empty
“choice” statement with the same description statement?
BALAZS: choice would not be a good solution because it would only allow one set of capabilities, while our goal is to allow different capability set side by side.

You misunderstand.  Adding an empty choice preserves the data model as is.  It’s just a more "YANG way” to do what you have:

OLD:
    // augmentation point for system level capabilities

NEW:
   choice system-capabilities {
      // mandatory true;  // must at least one exist?
      description 
         "augmentation point for system level capabilities.”;
   }

In our opinion,  the choice is not an ideal solution. For the choice you may only select one case. We, on the other hand, want to allow multiple augmentations to be used at the same time. If we used a choice, we could not allow multiple different cases/augmentations to be used at the same time. It is a question of on-of-many versus any-number.



- rather than have the “description” statement "// augmentation
augmentation point for datastore or data node level capabilities”,
why not have an empty “choice” statement with the same
description statement?
BALAZS: see above.

Also see above  ;)
Also see above ;)


- is the comment "The special value '/' denotes all data nodes in the
datastore.” should state if it’s a CLR or simply consistent with XPath 1.0 expressions.
BALAZS: we are consistent witjh the NACM RFC, which says:
                    The special value '/' refers to all possible
                    datastore contents.";

Then the comment should say “As specified in NACM Section ???, the special value…”, right?
Done.
          leaf node-selector {
            type nacm:node-instance-identifier;
            description
              "Selects the data nodes for which capabilities are
               specified. The special value '/' denotes all data nodes
               in the datastore, as specified in path YANG object in
               data definition statement [RFC8341];
            reference
                  "RFC 8341: Network Configuration Access Control Model";
          }



- this command detected an issue: pyang --ietf ietf-system-capabilities\@2020-03-23.yang.
(I’m unsure why, exactly, as I see the keywords block in the module
$ pyang --ietf ietf-system-capabilities.yang
$
$ pyang -v
pyang 2.4.0

…suggest copying
text directly from `pyang --ietf-help`.

No response?
That was an oversight. Done.



- this command detected a number of issues: pyang -f yang --keep-comments --yang-line-length 69 ietf-notification-capabilities\@2020-03-23.yang > tmp; diff ietf-notification-capabilities\@2020-03-23.yang tmp. (whitespace at end of lines)

No response?
That was an oversight. Done for both modules





- through draft (in both body and YANG modules), bracket datastore names with
angle brackets (e.g., s/running/<running>/) wherever the datastore name is NOT
followed by word “datastore”. When the datastore name is NOT followed by the
word “datastore", the datastore name should be in quotes, where it makes sense
to do so. BTW, I note the none of the datastore names are imported as terms or
otherwise introduced where first used...
Benoit: Done

I don’t see these changes...
What I did in the previous draft version: I searched for all instances of running, and it's always followed by the word datastore. I did the same for candidate, operational (there are no instances of startup and intended).
I double-checked this new version too.

Added a reference to RFC 8342 with the first occurrence of datastore in the intro.



- the YANG Doctor review suggested adding comments regarding
if imports needed to be implemented. I see such comments were
added in -06 but they’ve subsequently been removed. I strongly
second Lada’s suggestion to include a minimal YANG Library
instance somewhere, not only to document which modules need to be implemented, but also to document the totality of them, as I
was unpleasantly surprised by how many there were (12 in total!)
BALAZS: OK, Included for the 3 imports that need implemented. They were removed due to comments, but I like the sentences.

Better, but no YANG Library instance?  Oh well.

Thanks for your review.

I'll be posting a new version soon.

Regards, Balazs and Benoit


K.



--------------472DA84163887128C9007B07-- From nobody Fri Apr 2 13:02:37 2021 Return-Path: <01000178942e1633-ed64aaba-cc99-4893-989d-890bbd202ca5-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 841213A2197 for ; Fri, 2 Apr 2021 13:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 IqLbmgd2oHes for ; Fri, 2 Apr 2021 13:02:33 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7C53A2193 for ; Fri, 2 Apr 2021 13:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1617393751; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=+p3FbKgqCHzM5vrJSodwBe0YyhyTwVkQ8VNqdz//ajc=; b=YVCWd1HSDB7mu1Hw7ZU1kTKaZp8oXdY6IxJ/xwbTV0eXMc6xuNRebftXZ2X7JCyQ u72FqpG4UiEnvwS6U7wjyiX5U/NgCm7CN1Hv/1dlUuVgSfL/lhanhFvgtlLdxskKQKx YxcKNk0P93/bhl8fBclOZ3pyHwrOHAlHN89rZgsQ= 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 In-Reply-To: <5303-60677180-31-62233d80@261934540> Date: Fri, 2 Apr 2021 20:02:31 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000178942e1633-ed64aaba-cc99-4893-989d-890bbd202ca5-000000@email.amazonses.com> References: <5303-60677180-31-62233d80@261934540> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.04.02-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 20:02:36 -0000 Hi Michal, > firstly I am sorry, somehow I missed this reply, my bad :( No worries! :) >>> I had a chance to look at these modules again and have 2 questions = regarding some recent changes. >>>=20 >>> - ietf-ssh-server, = ssh-server-grouping/client-authentication/supported-authentication-methods= >=20 >>> Since the "other" leaf-list was removed there is no way to support = some other methods than those specified. I am not sure whether this was = the intention and if so, what is the reason for it? If nothing else, we = support "interactive" authentication method but there are some others = that I see no reason why they could not be used. >>=20 >> It took me a bit to determine that this change happened in = ssh-client-server-18. >>=20 >> The motivation behind the change was to align the values with those = defined in RFCs 4252 and 4250. >>=20 >> You mention an =E2=80=9Cinteractive=E2=80=9D and =E2=80=9Csome = other=E2=80=9D methods - where are they defined? >=20 > That is a good question. It seems no other methods are standardized = but that does not mean they are not used. What change are you hoping to see? Is there anyway that such changes = could be augmented in, or must they be in the base module? >>> For a robust and extendible solution, why not use an identityref = leaf-list with all the methods as identities? One could then simply add = new ones with specific "if-feature" statements. >>=20 >> An identityref seems reasonable, could you propose a snippet of YANG = for it? >>=20 >> That said, it seems equally possible for a future module to = augment-in a new leaf under the "supported-authentication-methods=E2=80=9D= container... >=20 > Right, that would solve the problem, too. So you can keep it the way = it is, up to you which solution you prefer. Not sure why I did not think = of augments first but identityrefs. But identityrefs are much more = general so the implementation should probably depend on whether these = authentication methods are to be used only for this single purpose or = not. Either way is fine with me. As the module is in WGLC currently, it = would be good if others could express an option... >>> - ietf-netconf-server, grouping = netconf-server-grouping/client-identity-mappings >>>=20 >>> The "if-feature" on this container is strange. The practical problem = is that if one wants to support certificates only for TLS, both one of = the TLS features and "ssh-x509-certs" must be enabled. This then results = in the container being defined for both SSH and TLS so there is no way = to support it only for TLS or SSH. >>=20 >> Yes, granular features would be nice. This issue is tracked here: = https://github.com/netmod-wg/yang-next/issues/82 = . A possible fix = would be to enable features on a per-XPath basis, perhaps using the = =E2=80=9Cnode-tags=E2=80=9D draft going on in NETMOD. Do you have a = proposal? >>=20 >> BTW, shouldn=E2=80=99t the =E2=80=9Cif-feature=E2=80=9D statement = have an =E2=80=9Cor=E2=80=9D (not an =E2=80=9Cand=E2=80=9D) between the = two major expressions? >=20 > Yes, I think "or" fits much better. I just was not sure whether there = is not a specific reason why "and" was chosen. OLD: "(tls-listen or tls-call-home) and = (sshcmn:ssh-x509-certs)=E2=80=9D; NEW: "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; But what about your original question, are you okay with consuming = modules augmenting-in use-specific if-feature statements?=20 K. From nobody Fri Apr 2 13:18:36 2021 Return-Path: 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 0F0FC3A221A for ; Fri, 2 Apr 2021 13:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 9FfPtDjbMhYf for ; Fri, 2 Apr 2021 13:18:26 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440E03A221B for ; Fri, 2 Apr 2021 13:18:26 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id z8so6595171ljm.12 for ; Fri, 02 Apr 2021 13:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4IyyCK1jmtrdzgxZMKl/8liXdCyy51e7g2XijYTc3bY=; b=JkKNQ+/kaOXv4ofn1M9huFIEFKjfkTjkaJRxHxtQ5MDh5BhJNzeu9PC1sAEzhBZs6e h1lhT41AUlW/qvJwnt3LxvYMmoBbmXtm5PDQpyXzWyxdhFDaOT8RHk+Qt8kDzmurMg75 PgwilXwonnnGVTHtgpCpyK4WBmD+a7PT1sox8ei2PB7+GaZQFDOzIuk8uzmLyjff21A8 l8n+xMVuon1OTM3mYb4OABtLMB9IVxH5uNoA0npyl6HF7EF3Uu3DkGiLzkUdG3SGhDhH vHULGkOz0cUeVwVmv+qspJusYir4XWR5QC2y8y96b7RyBDi0paoMvfROCoS1XOWZBMcb XGkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4IyyCK1jmtrdzgxZMKl/8liXdCyy51e7g2XijYTc3bY=; b=AtzgIVJhnyEKaF375FGGntoj3W/XS3uAVilI6B/nWOQrKNomGCE+kPCO1Qs5KQymyv zWkzVQXvVyuPM5Z/snuo2QFLF1kNnSM70oVwauicg6rATOu+qtbuFQWZET5ZPyKpqBAv MVrnX0uA3U9oG/EowbaAATvlV+qDbvRGFZqfzdf/wYDtwyib4Y4JKyl1CPKivU3Zfbmz Ea0/mx98HnVD9KbHjrFPwz8PR1EShqjpwBcvwOHltEBopA35lEF0d4h2vdiO1sURA637 /L+cXGRRO11uADmCR0+fVq+wMfYW5BSn02vfTtBl3p01IKpatnrd3tEu35rrmyUadEpa 6Kyg== X-Gm-Message-State: AOAM533SHuufkTFEv/fU+nA+7J3Fpd/9ZCkViXAYicj4yxLo+5iUxmEF lwAYf98PBnRGLAjVbqJ8wvBttdbUVbvg6323sY/jrQ== X-Google-Smtp-Source: ABdhPJzD88TtHqHGalaeA7DjyDXCbv9TpKIwIkHVq/CdIv2rDniTpoERkPWYoS9nrsgx00fjgCfoSAQHWHbRvpmJ2C8= X-Received: by 2002:a2e:2c0d:: with SMTP id s13mr9073566ljs.105.1617394701988; Fri, 02 Apr 2021 13:18:21 -0700 (PDT) MIME-Version: 1.0 References: <5830-60677580-9-1569b540@260964559> In-Reply-To: <5830-60677580-9-1569b540@260964559> From: Andy Bierman Date: Fri, 2 Apr 2021 13:18:11 -0700 Message-ID: To: =?UTF-8?Q?Michal_Va=C5=A1ko?= Cc: "Eric Voit (evoit)" , netconf , netmod Content-Type: multipart/alternative; boundary="000000000000ac893d05bf030ce5" Archived-At: Subject: Re: [netconf] YANG Push module errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 20:18:31 -0000 --000000000000ac893d05bf030ce5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 2, 2021 at 12:49 PM Michal Va=C5=A1ko wrote: > Hi Eric, > > thanks for the answer. > > On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" > wrote: > > > Hi Michal, > > > > This sounds like a tooling issue to me. I would expect that any augmen= ts > > would inherit the conditional nature of anything augmented. > > Perhaps, but there is nothing in the specification to hint this. On the > contrary, leafrefs, for example, explicitly require to be conditional on > the same set of if-features than their targets. But you are right, there = is > no such requirements for augments. Still, if the feature is disabled and > the augment should be applied, since its target does not technically exis= t > in the schema, it cannot be found. That is the error our tools currently > produce. > > Maybe this is not clear enough in RFC 7950. This seems valid: container foo { if-feature X; leaf bar { type string; } } augment /foo { container Y; } The YANG syntax validation should be done as if all features are enabled. It is a tooling issue if this is rejected. This is clear because the augment-stmt argument specifies a schema node. Another related issue: container zed { leaf baz { type leafref { path /foo/bar; } } } This example is not clear because the path-stmt argument specifies a data node. Is it also valid YANG to have a leafref in an unconditional leaf point at an if-feature conditional leaf? Does leaf baz need "if-feature X" added? Is this a syntax error? A run-time error? Neither? Is it invalid or does leaf /zed/baz simply have an empty value set? Is it OK for a leafref node to have an empty value set? This corner case keeps coming up in real YANG modules so it would be great if the standard clarified this behavior. Andy > > If you disagree, perhaps a thread to the netmod alias would get you an > > 'official' answer on the proper behavior. > > I have sent the email to "netconf" because that is WG that published it > but no harm in adding a copy for "netmod". > > > Eric > > > > > -----Original Message----- > > > From: netconf On Behalf Of Michal Va=C5=A1= ko > > > Sent: Thursday, April 1, 2021 11:14 AM > > > To: netconf > > > Subject: [netconf] YANG Push module errors > > > > > > Hi, > > > > > > we are led to believe there is an error in the ietf-yang-push module > > published in > > > RFC 8641 but I wanted to discuss it here before submitting an errata. > > There are 2 > > > augments [1] on a notification that is conditional on "configured" > feature > > but > > > these 2 augments are not conditional. Having this feature disabled, w= e > > were not > > > able to load this module into our tools. Does anyone disagree with > this or > > with > > > submitting an errata? > > > > > > Regards, > > > Michal > > > > > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000ac893d05bf030ce5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 2, 2021 at 12:49 PM Micha= l Va=C5=A1ko <mvasko@cesnet.cz&g= t; wrote:
Hi Eri= c,

thanks for the answer.

On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" <evoit@cisco.com> w= rote:

> Hi Michal,
>
> This sounds like a tooling issue to me.=C2=A0 I would expect that any = augments
> would inherit the conditional nature of anything augmented.=C2=A0

Perhaps, but there is nothing in the specification to hint this. On the con= trary, leafrefs, for example, explicitly require to be conditional on the s= ame set of if-features than their targets. But you are right, there is no s= uch requirements for augments. Still, if the feature is disabled and the au= gment should be applied, since its target does not technically exist in the= schema, it cannot be found. That is the error our tools currently produce.=


Maybe this is not clear enough in RFC = 7950.

This seems valid:

= =C2=A0 =C2=A0 container foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0if-featu= re X;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf bar { type string; }
=
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 augment /foo {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 container Y;
=C2=A0 =C2=A0 = }

The YANG syntax validation should be done as if = all features are enabled.
It is a tooling issue if=C2=A0this is r= ejected. This is clear because the augment-stmt
argument specifie= s a schema node.

Another related issue:
=
=C2=A0 =C2=A0container zed {
=C2=A0 =C2=A0 =C2=A0 = leaf baz {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref = {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path /foo/bar;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2= =A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 }


<= /div>
This example is not clear because the=C2=A0path-stmt argument spe= cifies a data node.

Is it also valid YANG to have = a leafref in an unconditional leaf point at an if-feature conditional=C2=A0= leaf?
Does leaf baz need "if-feature X" added?
Is this a syntax error? A run-time error?=C2=A0 Neither?
Is it = invalid or does leaf /zed/baz simply have an empty value set?
Is = it OK for a leafref node to have an empty value set?

This corner case=C2=A0keeps coming up in real YANG modules so it would b= e great
if the standard clarified this behavior.


Andy

=C2=A0
> If you disagree, perhaps a thread to the netmod alias would get you an=
> 'official' answer on the proper behavior.

I have sent the email to "netconf" because that is WG that publis= hed it but no harm in adding a copy for "netmod".

> Eric
>
> > -----Original Message-----
> > From: netconf <netconf-bounces@ietf.org> On Behalf Of Michal Va=C5= =A1ko
> > Sent: Thursday, April 1, 2021 11:14 AM
> > To: netconf <netconf@ietf.org>
> > Subject: [netconf] YANG Push module errors
> >
> > Hi,
> >
> > we are led to believe there is an error in the ietf-yang-push mod= ule
> published in
> > RFC 8641 but I wanted to discuss it here before submitting an err= ata.
> There are 2
> > augments [1] on a notification that is conditional on "confi= gured" feature
> but
> > these 2 augments are not conditional. Having this feature disable= d, we
> were not
> > able to load this module into our tools. Does anyone disagree wit= h this or
> with
> > submitting an errata?
> >
> > Regards,
> > Michal
> >
> > [1] https://tools.ietf.org/html/rfc8641#page-= 48 and the next page
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf=

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000ac893d05bf030ce5-- From nobody Sat Apr 3 06:08:05 2021 Return-Path: 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 93D073A0B8A; Sat, 3 Apr 2021 06:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=nic.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 uYfByeKEnVaw; Sat, 3 Apr 2021 06:07:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D403A0B6C; Sat, 3 Apr 2021 06:07:57 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id CA9B0140072; Sat, 3 Apr 2021 15:07:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1617455269; bh=SplQ8u1KnCCg20lfrULrKwd+0xhNCoGxypzeIztTBNI=; h=From:To:Date; b=tePl5TO/sA02dcSt6oYG5doA1p/7473vWZbY8HCgFlXtvVbioZ02UsZmbLWQNO24E cnuu4v0uWyHV/cc2BQXSVow3JHb/inTwRiLjDnJwFkL6QFgkGJeOC1HwBpZ24PY/Wj rlEuFnztt8yh+UnqTr2cUxHWnjNhBqib+7sVGXic= From: Ladislav Lhotka To: Andy Bierman , Michal =?utf-8?Q?Va=C5=A1ko?= Cc: "Eric Voit (evoit)" , netconf , netmod In-Reply-To: References: <5830-60677580-9-1569b540@260964559> Mail-Followup-To: Andy Bierman , Michal =?utf-8?Q?Va?= =?utf-8?Q?=C5=A1ko?= , "Eric Voit (evoit)" , netconf , netmod Date: Sat, 03 Apr 2021 15:07:48 +0200 Message-ID: <878s5ztt23.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] [netmod] YANG Push module errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2021 13:08:04 -0000 Andy Bierman writes: > On Fri, Apr 2, 2021 at 12:49 PM Michal Va=C5=A1ko wrot= e: > >> Hi Eric, >> >> thanks for the answer. >> >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" >> wrote: >> >> > Hi Michal, >> > >> > This sounds like a tooling issue to me. I would expect that any augme= nts >> > would inherit the conditional nature of anything augmented. >> >> Perhaps, but there is nothing in the specification to hint this. On the >> contrary, leafrefs, for example, explicitly require to be conditional on >> the same set of if-features than their targets. But you are right, there= is >> no such requirements for augments. Still, if the feature is disabled and >> the augment should be applied, since its target does not technically exi= st >> in the schema, it cannot be found. That is the error our tools currently >> produce. >> >> > Maybe this is not clear enough in RFC 7950. > > This seems valid: > > container foo { > if-feature X; > leaf bar { type string; } > } > > augment /foo { > container Y; > } > > The YANG syntax validation should be done as if all features are enabled. > It is a tooling issue if this is rejected. This is clear because the > augment-stmt argument specifies a schema node. Agreed. > > Another related issue: > > container zed { > leaf baz { > type leafref { > path /foo/bar; > } > } > } This is not permitted, see section 9.9 in RFC 7950: If the leaf that the leafref refers to is conditional based on one or more features (see Section 7.20.2), then the leaf with the leafref type MUST also be conditional based on at least the same set of features. Lada > > > This example is not clear because the path-stmt argument specifies a data > node. > > Is it also valid YANG to have a leafref in an unconditional leaf point at > an if-feature conditional leaf? > Does leaf baz need "if-feature X" added? > Is this a syntax error? A run-time error? Neither? > Is it invalid or does leaf /zed/baz simply have an empty value set? > Is it OK for a leafref node to have an empty value set? > > This corner case keeps coming up in real YANG modules so it would be great > if the standard clarified this behavior. > > > Andy > > > >> > If you disagree, perhaps a thread to the netmod alias would get you an >> > 'official' answer on the proper behavior. >> >> I have sent the email to "netconf" because that is WG that published it >> but no harm in adding a copy for "netmod". >> >> > Eric >> > >> > > -----Original Message----- >> > > From: netconf On Behalf Of Michal Va=C5= =A1ko >> > > Sent: Thursday, April 1, 2021 11:14 AM >> > > To: netconf >> > > Subject: [netconf] YANG Push module errors >> > > >> > > Hi, >> > > >> > > we are led to believe there is an error in the ietf-yang-push module >> > published in >> > > RFC 8641 but I wanted to discuss it here before submitting an errata. >> > There are 2 >> > > augments [1] on a notification that is conditional on "configured" >> feature >> > but >> > > these 2 augments are not conditional. Having this feature disabled, = we >> > were not >> > > able to load this module into our tools. Does anyone disagree with >> this or >> > with >> > > submitting an errata? >> > > >> > > Regards, >> > > Michal >> > > >> > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page >> > > >> > > _______________________________________________ >> > > netconf mailing list >> > > netconf@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netconf >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Apr 5 04:16:21 2021 Return-Path: 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 7FD1B3A139A for ; Mon, 5 Apr 2021 04:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=IonU2Cp/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LTk26jDT 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 vB6TzU6q4qBI for ; Mon, 5 Apr 2021 04:16:14 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602993A1398 for ; Mon, 5 Apr 2021 04:16:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2D03617A8; Mon, 5 Apr 2021 07:16:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 05 Apr 2021 07:16:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= j4lYU2JT/J+Az8mRB+2pBmCXK2Y70rHajz0aydCEUe0=; b=IonU2Cp/imM+XLd9 w2vHEcXyzHsJYeOPRBnF2kb5CzjrJqf6p5P8FxAtLc7jbzYsyjGtOTcCTTpLUITk Zl8/s3oj9N5muZiNcYaC1ChxLusRbrAWTzoRf6a8Bw5vZ8tzOayYhvgYQyTmUCMe eb3ZUDezxRitoYXyDQ0jYUpAdtjlZACt+TvetQ0WXoI4DkKooyFL0mrfX4Qz0yxA 8S4alvvKPJE8vpbIw/PJokWJG60Mx2DkiFpGt0GX57O3TlUUvrgkxY/1a7nRzDb4 ZZOPqVsayydJV9jqB64aTCwbbNqjj1zLRCXNSUp/ZgXNtTyiSdEPmYqT/XZ3gQqv 91mItw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=j4lYU2JT/J+Az8mRB+2pBmCXK2Y70rHajz0aydCEU e0=; b=LTk26jDTudpyRuu0vMxaXNj7IQAF3aZ7jHvXOMVzkeWtxbp8aN+0g0fCV DiAHy8naA3xXGoVgdKUhc+qYXZ3FeAw6BPH1CPXRNYGjJdlljhkEQBVhqW9/f9jd MxI/0Xz2h7b3/gxGunhuDOpkF19Yt9qHYqVD0ugc0p0OL7Sx8rDZxXm6uPYKuHWm PptW5Q6clw+zNM38cn2KW3sifZx+9686mU7jjX0C51Q7KHg50hwMYcgy/t7SH5Uz wRRuVp+gap+7g+1NeOX8ug7gXLeBaVN4Tmp7YxCxdXCzIIat9pKlD4Z3fRTmtOlP ancKUbaiqpaIXvb61ZnZylYGydOIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudejvddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnheptedvfffhgeejffeljeeuve ekudevfeduudduteetveelieekgfdtieekudeiudevnecuffhomhgrihhnpehgihhthhhu sgdrtghomhenucfkphepudehkedrudejgedrgedrvdduheenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhs vg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A776240057; Mon, 5 Apr 2021 07:16:06 -0400 (EDT) Date: Mon, 05 Apr 2021 13:16:04 +0200 (CEST) Message-Id: <20210405.131604.1874714527132991309.id@4668.se> To: andy@yumaworks.com Cc: kent+ietf@watsen.net, mbj@tail-f.com, netconf@ietf.org, warren@kumari.net, rfc-editor@rfc-editor.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: References: <01000178932683b3-f9a114b8-b525-479e-b7f2-ff8300b32d14-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8341 (6493) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 11:16:20 -0000 Andy Bierman wrote: > On Fri, Apr 2, 2021 at 8:14 AM Kent Watsen wrote: > > > > > I agree with Juergen that section 9.13.2 of RFC 7950 applies and hence my > > opinion is that this errata, against RFC 8341, should be rejected. > > > > > > +1 (as contributor) > > > > > > However, I also think that RFC 7950 isn't as clear as it should be. Given > > that there is an explicit ABNF construct for instance-identifier, I really > > think that this ABNF should explicitly require prefixes for > > node-identifiers, avoiding any potential ambiguity in what is allowed. > > > > > > Should a YANG-next issue be filed? > > > > > We could think a bit about the real problems with instance-identifier > instead of academic discussions. > > The ABNF only describes the syntax of the default-stmt representation of an > instance-identifier. > Since such a default would be extremely rare, this is not an interesting > problem. > The RFC is clear that prefixes are required. > > The protocol message (or artifact) representation of an instance-identifier > is a much more relevant use-case. > XML has its own rules for binding namespaces to QNames in the context of an > XML instance document. > These rules are clear, so no problem to be solved here. > > The real problem (for yang-next?) is that the instance-identifier and > identityref data types > do not have any context-free representation possible, let alone a canonical > representation. There is an YANG-next issue for this problem (https://github.com/netmod-wg/yang-next/issues/56) /martin > > The solution already exists in RFC 7951 (6.8 and 6.11). > These encoding rules for identityref and instance-identifier should be used > for all > representations, and the default-stmt, The XML and YANG encodings should be > replaced > (by introducing new types and deprecating the old ones). > > > > > > K. > > > > > Andy From nobody Mon Apr 5 07:07:28 2021 Return-Path: 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 5785F3A1A31 for ; Mon, 5 Apr 2021 07:07:26 -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 eWmdWq_9hUM3 for ; Mon, 5 Apr 2021 07:07:21 -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 249FC3A1A30 for ; Mon, 5 Apr 2021 07:07:20 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 5846460084; Mon, 5 Apr 2021 16:07:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1617631635; bh=LjQ2ZjuCXDWx0QuO21sVe1T60hUpxwPkmDnEL/Nerko=; h=From:In-Reply-To:Date:Cc:To:Subject; b=gg0ZrQrPxPn6XGKwLp2i3303YkkYxDTit0Oj/i62z+XwzqXxpVYGPXBj1VaPpWSt2 7yohcvSLZ9pojiOBpuV/6gADUh827wOFb/gm240qQKf4mJFf+uHweroND4rpynJrPM jMw8F789CqRF5qCb6tC5krPeuKWbbdqH4pqzMJpE= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <01000178942e1633-ed64aaba-cc99-4893-989d-890bbd202ca5-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Mon, 05 Apr 2021 16:07:15 +0200 Cc: "netconf@ietf.org" To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <66c7-606b1980-11-21ab2140@196626001> User-Agent: SOGoMail 5.0.1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 14:07:26 -0000 Hi Kent, > > firstly I am sorry, somehow I missed this reply, my bad :( > > No worries! :) > > > >>> I had a chance to look at these modules again and have 2 question= s regarding some recent changes. > >>> > >>> - ietf-ssh-server, ssh-server-grouping/client-authentication/supp= orted-authentication-methods> > >>> Since the "other" leaf-list was removed there is no way to suppor= t some other methods than those specified. I am not sure whether this w= as the intention and if so, what is the reason for it? If nothing else,= we support "interactive" authentication method but there are some othe= rs that I see no reason why they could not be used. > >> > >> It took me a bit to determine that this change happened in ssh-cli= ent-server-18. > >> > >> The motivation behind the change was to align the values with thos= e defined in RFCs 4252 and 4250. > >> > >> You mention an =E2=80=9Cinteractive=E2=80=9D and =E2=80=9Csome oth= er=E2=80=9D methods - where are they defined? > > > > That is a good question. It seems no other methods are standardized= but that does not mean they are not used. > > What change are you hoping to see? Is there anyway that such changes= could be augmented in, or must they be in the base module? Okay, so properly looking at all this, the 2 missing authentication met= hods (that are supported by libssh or sshd, or example) are actually st= andardized so I suppose you can add them directly into the YANG module.= There are "keyboard-interactive" [1] (not "interactive") and "gssapi-w= ith-mic" [2]. [1] https://tools.ietf.org/html/rfc4256 [2] https://tools.ietf.org/html/rfc4462 > >>> For a robust and extendible solution, why not use an identityref = leaf-list with all the methods as identities? One could then simply add= new ones with specific "if-feature" statements. > >> > >> An identityref seems reasonable, could you propose a snippet of YA= NG for it? > >> > >> That said, it seems equally possible for a future module to augmen= t-in a new leaf under the "supported-authentication-methods=E2=80=9D co= ntainer... > > > > Right, that would solve the problem, too. So you can keep it the wa= y it is, up to you which solution you prefer. Not sure why I did not th= ink of augments first but identityrefs. But identityrefs are much more = general so the implementation should probably depend on whether these a= uthentication methods are to be used only for this single purpose or no= t. > > Either way is fine with me. As the module is in WGLC currently, it w= ould be good if others could express an option... > > > > >>> - ietf-netconf-server, grouping netconf-server-grouping/client-id= entity-mappings > >>> > >>> The "if-feature" on this container is strange. The practical prob= lem is that if one wants to support certificates only for TLS, both one= of the TLS features and "ssh-x509-certs" must be enabled. This then re= sults in the container being defined for both SSH and TLS so there is n= o way to support it only for TLS or SSH. > >> > >> Yes, granular features would be nice. This issue is tracked here:= https://github.com/netmod-wg/yang-next/issues/82 . A possible fix would be to enable featu= res on a per-XPath basis, perhaps using the =E2=80=9Cnode-tags=E2=80=9D= draft going on in NETMOD. Do you have a proposal? > >> > >> BTW, shouldn=E2=80=99t the =E2=80=9Cif-feature=E2=80=9D statement = have an =E2=80=9Cor=E2=80=9D (not an =E2=80=9Cand=E2=80=9D) between the= two major expressions? > > > > Yes, I think "or" fits much better. I just was not sure whether the= re is not a specific reason why "and" was chosen. > > OLD: "(tls-listen or tls-call-home) and (sshcmn:ssh-x509-certs= )=E2=80=9D; > NEW: "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; Well, this is no good either because now ANY of those features are enab= led, the certificates will be supported for BOTH TLS and SSH. What shou= ld be possible to support is X509 certificates for SSH, TLS, or both. T= hat would require some more remodeling of "netconf-server-grouping", no= t just an "if-feature" update. Regards, Michal > > But what about your original question, are you okay with consuming mo= dules augmenting-in use-specific if-feature statements? > > > K. > > > > > From nobody Mon Apr 5 07:23:43 2021 Return-Path: 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 784343A1AC0; Mon, 5 Apr 2021 07:23:42 -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 02lnaB9DT4b8; Mon, 5 Apr 2021 07:23:37 -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 11B713A1ABF; Mon, 5 Apr 2021 07:23:36 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 5A37060086; Mon, 5 Apr 2021 16:23:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1617632614; bh=sqRIyi3TaHbmA29HI9qsROUlY3383gNY8XFCPcUrGYs=; h=From:In-Reply-To:Date:Cc:To:Subject; b=W6XVCGT163NM2ScvZI0jgf8Mq6G0KbnjBgcMYFs1rNQ4n3XWtRAe3k8wbjcU1rUc/ mdf6o8Klec/PZ6HioV2ebaulONqK2YQgHaCuI4uekw5xsZdD4+U+x3cIFx4NwQMZV5 3raMw6/ZPgtNDsPXIDSaw8UMjTWF/yJX+qfgG0dg= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <878s5ztt23.fsf@nic.cz> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Mon, 05 Apr 2021 16:23:34 +0200 Cc: "Andy Bierman" , "Eric Voit (evoit)" , "netconf" , "netmod" To: "Ladislav Lhotka" MIME-Version: 1.0 Message-ID: <52f2-606b1d80-d-7afd9d00@152658395> User-Agent: SOGoMail 5.0.1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?=5Bnetmod=5D__YANG_Push_module_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 14:23:42 -0000 On Saturday, April 03, 2021 15:07 CEST, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Fri, Apr 2, 2021 at 12:49 PM Michal Va=C5=A1ko wrote: > > > >> Hi Eric, > >> > >> thanks for the answer. > >> > >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" > >> wrote: > >> > >> > Hi Michal, > >> > > >> > This sounds like a tooling issue to me. I would expect that any= augments > >> > would inherit the conditional nature of anything augmented. > >> > >> Perhaps, but there is nothing in the specification to hint this. O= n the > >> contrary, leafrefs, for example, explicitly require to be conditio= nal on > >> the same set of if-features than their targets. But you are right,= there is > >> no such requirements for augments. Still, if the feature is disabl= ed and > >> the augment should be applied, since its target does not technical= ly exist > >> in the schema, it cannot be found. That is the error our tools cur= rently > >> produce. > >> > >> > > Maybe this is not clear enough in RFC 7950. > > > > This seems valid: > > > > container foo { > > if-feature X; > > leaf bar { type string; } > > } > > > > augment /foo { > > container Y; > > } > > > > The YANG syntax validation should be done as if all features are en= abled. > > It is a tooling issue if this is rejected. This is clear because th= e > > augment-stmt argument specifies a schema node. > > Agreed. I see. Okay, thanks for the clarification and yes, if this was explicit= ly mentioned in the RFC it would be great. Although, the validity of yo= ur example was not in question. Rather something like: container foo { if-feature X; container bar; } augment /foo/bar { container Y; } I am just going to assume this is what you meant and simply that the re= quirement is that any schema path must point to an existing schema node= , ignoring any "if-feature" statements. Regards, Michal > > > > Another related issue: > > > > container zed { > > leaf baz { > > type leafref { > > path /foo/bar; > > } > > } > > } > > This is not permitted, see section 9.9 in RFC 7950: > > If the leaf that the leafref refers to is conditional based on one= or > more features (see Section 7.20.2), then the leaf with the leafref= > type MUST also be conditional based on at least the same set of > features. > > Lada > > > > > > > This example is not clear because the path-stmt argument specifies = a data > > node. > > > > Is it also valid YANG to have a leafref in an unconditional leaf po= int at > > an if-feature conditional leaf? > > Does leaf baz need "if-feature X" added? > > Is this a syntax error? A run-time error? Neither? > > Is it invalid or does leaf /zed/baz simply have an empty value set?= > > Is it OK for a leafref node to have an empty value set? > > > > This corner case keeps coming up in real YANG modules so it would b= e great > > if the standard clarified this behavior. > > > > > > Andy > > > > > > > >> > If you disagree, perhaps a thread to the netmod alias would get = you an > >> > 'official' answer on the proper behavior. > >> > >> I have sent the email to "netconf" because that is WG that publish= ed it > >> but no harm in adding a copy for "netmod". > >> > >> > Eric > >> > > >> > > -----Original Message----- > >> > > From: netconf On Behalf Of Michal V= a=C5=A1ko > >> > > Sent: Thursday, April 1, 2021 11:14 AM > >> > > To: netconf > >> > > Subject: [netconf] YANG Push module errors > >> > > > >> > > Hi, > >> > > > >> > > we are led to believe there is an error in the ietf-yang-push = module > >> > published in > >> > > RFC 8641 but I wanted to discuss it here before submitting an = errata. > >> > There are 2 > >> > > augments [1] on a notification that is conditional on "configu= red" > >> feature > >> > but > >> > > these 2 augments are not conditional. Having this feature disa= bled, we > >> > were not > >> > > able to load this module into our tools. Does anyone disagree = with > >> this or > >> > with > >> > > submitting an errata? > >> > > > >> > > Regards, > >> > > Michal > >> > > > >> > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next p= age > >> > > > >> > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F > >> > > netconf mailing list > >> > > netconf@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/netconf > >> > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > >> netconf mailing list > >> netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 6 00:05:09 2021 Return-Path: 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 623603A11ED; Tue, 6 Apr 2021 00:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 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, RCVD_IN_DNSWL_MED=-2.3, 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=nic.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 cG8sGS-LMx8y; Tue, 6 Apr 2021 00:05:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282DB3A11EB; Tue, 6 Apr 2021 00:05:02 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 98932140881; Tue, 6 Apr 2021 09:04:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1617692693; bh=ZIUE2K+GMNXuALNM53mDy2SrzcZsI47o5/7KPl7AcSs=; h=From:To:Date; b=UXGsNBRv7ZgiBZ9FYUfW/vJ4kGWrtsIN+iDP3vAg7VJ5SEJFaXoRFHbpKjGXi7BxS 6SHg4nbLvTgXCHwyDtEceG+aF1D5RjpkCWKjJqIbYy60cCoLjMvSc6SVMTf8mdQGCz ht66KmQ1sD5s3izDtOTXIi6w5yfvS83gfcvgzWuo= From: Ladislav Lhotka To: Michal =?utf-8?Q?Va=C5=A1ko?= Cc: Andy Bierman , "Eric Voit (evoit)" , netconf , netmod In-Reply-To: <52f2-606b1d80-d-7afd9d00@152658395> References: <52f2-606b1d80-d-7afd9d00@152658395> Mail-Followup-To: Michal =?utf-8?Q?Va=C5=A1ko?= , Andy Bierman , "Eric Voit (evoit)" , netconf , netmod Date: Tue, 06 Apr 2021 09:04:53 +0200 Message-ID: <87wntf3nca.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] [netmod] YANG Push module errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 07:05:09 -0000 Michal Va=C5=A1ko writes: > On Saturday, April 03, 2021 15:07 CEST, Ladislav Lhotka wrote:=20 >=20=20 >> Andy Bierman writes: >>=20 >> > On Fri, Apr 2, 2021 at 12:49 PM Michal Va=C5=A1ko w= rote: >> > >> >> Hi Eric, >> >> >> >> thanks for the answer. >> >> >> >> On Friday, April 02, 2021 15:43 CEST, "Eric Voit (evoit)" >> >> wrote: >> >> >> >> > Hi Michal, >> >> > >> >> > This sounds like a tooling issue to me. I would expect that any au= gments >> >> > would inherit the conditional nature of anything augmented. >> >> >> >> Perhaps, but there is nothing in the specification to hint this. On t= he >> >> contrary, leafrefs, for example, explicitly require to be conditional= on >> >> the same set of if-features than their targets. But you are right, th= ere is >> >> no such requirements for augments. Still, if the feature is disabled = and >> >> the augment should be applied, since its target does not technically = exist >> >> in the schema, it cannot be found. That is the error our tools curren= tly >> >> produce. >> >> >> >> >> > Maybe this is not clear enough in RFC 7950. >> > >> > This seems valid: >> > >> > container foo { >> > if-feature X; >> > leaf bar { type string; } >> > } >> > >> > augment /foo { >> > container Y; >> > } >> > >> > The YANG syntax validation should be done as if all features are enabl= ed. >> > It is a tooling issue if this is rejected. This is clear because the >> > augment-stmt argument specifies a schema node. >>=20 >> Agreed. > > I see. Okay, thanks for the clarification and yes, if this was explicitly= mentioned in the RFC it would be great. Although, the validity of your exa= mple was not in question. Rather something like: > > container foo { > if-feature X; > container bar; > } > > augment /foo/bar { > container Y; > } > > I am just going to assume this is what you meant and simply that the requ= irement is that any schema path must point to an existing schema node, igno= ring any "if-feature" statements. I think it also depends on whether features are set before or after process= ing the modules. In the former case, an augment statement with an effective= ly missing target node can IMO be silently ignored, without even parsing it= s contents. Lada > > Regards, > Michal > >> > >> > Another related issue: >> > >> > container zed { >> > leaf baz { >> > type leafref { >> > path /foo/bar; >> > } >> > } >> > } >>=20 >> This is not permitted, see section 9.9 in RFC 7950: >>=20 >> If the leaf that the leafref refers to is conditional based on one or >> more features (see Section 7.20.2), then the leaf with the leafref >> type MUST also be conditional based on at least the same set of >> features. >>=20 >> Lada >>=20 >> > >> > >> > This example is not clear because the path-stmt argument specifies a d= ata >> > node. >> > >> > Is it also valid YANG to have a leafref in an unconditional leaf point= at >> > an if-feature conditional leaf? >> > Does leaf baz need "if-feature X" added? >> > Is this a syntax error? A run-time error? Neither? >> > Is it invalid or does leaf /zed/baz simply have an empty value set? >> > Is it OK for a leafref node to have an empty value set? >> > >> > This corner case keeps coming up in real YANG modules so it would be g= reat >> > if the standard clarified this behavior. >> > >> > >> > Andy >> > >> > >> > >> >> > If you disagree, perhaps a thread to the netmod alias would get you= an >> >> > 'official' answer on the proper behavior. >> >> >> >> I have sent the email to "netconf" because that is WG that published = it >> >> but no harm in adding a copy for "netmod". >> >> >> >> > Eric >> >> > >> >> > > -----Original Message----- >> >> > > From: netconf On Behalf Of Michal Va= =C5=A1ko >> >> > > Sent: Thursday, April 1, 2021 11:14 AM >> >> > > To: netconf >> >> > > Subject: [netconf] YANG Push module errors >> >> > > >> >> > > Hi, >> >> > > >> >> > > we are led to believe there is an error in the ietf-yang-push mod= ule >> >> > published in >> >> > > RFC 8641 but I wanted to discuss it here before submitting an err= ata. >> >> > There are 2 >> >> > > augments [1] on a notification that is conditional on "configured" >> >> feature >> >> > but >> >> > > these 2 augments are not conditional. Having this feature disable= d, we >> >> > were not >> >> > > able to load this module into our tools. Does anyone disagree with >> >> this or >> >> > with >> >> > > submitting an errata? >> >> > > >> >> > > Regards, >> >> > > Michal >> >> > > >> >> > > [1] https://tools.ietf.org/html/rfc8641#page-48 and the next page >> >> > > >> >> > > _______________________________________________ >> >> > > netconf mailing list >> >> > > netconf@ietf.org >> >> > > https://www.ietf.org/mailman/listinfo/netconf >> >> >> >> _______________________________________________ >> >> netconf mailing list >> >> netconf@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >>=20 >> --=20 >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 7 02:29:53 2021 Return-Path: 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 D93473A13BF; Wed, 7 Apr 2021 02:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=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=hs-esslingen.de 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 jFJ568Qmdesi; Wed, 7 Apr 2021 02:29:41 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A793D3A13BE; Wed, 7 Apr 2021 02:29:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1E4EB25B12; Tue, 6 Apr 2021 21:21:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1617736887; bh=5IZm8q9fPXkEhSrG98kZHrFde0D/efEmqffbODJsMYY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bIGsG3LldP9gc07d6O71wJVFVxGF6OPyUe2L4TTAYIz65eHAGWegwFjWr1/8oltaW 8t7h0xgpZbI+AMYU5tf9dJ5GB5gy/YlkI4oM7bOiBE5kRc1RO6bkFNI5VH3JzeDOFr Qe3B+tjzO9O1/ktPYBrkKF9xJcnl2QaSlUygvSd8= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LQv9Gw3ZMtI; Tue, 6 Apr 2021 21:21:26 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 6 Apr 2021 21:21:26 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 6 Apr 2021 21:21:25 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.009; Tue, 6 Apr 2021 21:21:25 +0200 From: "Scharf, Michael" To: Mahesh Jethanandani , "netconf@ietf.org" CC: tcpm IETF list Thread-Topic: [netconf] WGLC for draft-ietf-netconf-tcp-client-server Thread-Index: AQHXIqD5efHe7Em2SUeq9T5051qlEqqn5VqQ Date: Tue, 6 Apr 2021 19:21:25 +0000 Message-ID: <14240f263d0c4834b943353d1e9da314@hs-esslingen.de> References: <7CAA30A6-8E26-4B0F-B0D0-DB376806B922@gmail.com> In-Reply-To: <7CAA30A6-8E26-4B0F-B0D0-DB376806B922@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: multipart/alternative; boundary="_000_14240f263d0c4834b943353d1e9da314hsesslingende_" MIME-Version: 1.0 Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-tcp-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 09:29:46 -0000 --_000_14240f263d0c4834b943353d1e9da314hsesslingende_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGFtIGEgY28tYXV0aG9yIG9mIHRoaXMgSS1ELCBzbyBpZiBzb21ldGhpbmcg aXMgbWlzc2luZyBpbiB0aGlzIEktRCwgdGhpcyBpcyBieSBhbmQgbGFyZ2UgbXkgb3duIGZhdWx0 4oCmDQoNCk5vbmV0aGVsZXNzLCBJIHRoaW5rIEkgaGF2ZSBwcm9taXNlZCBsYXN0IHllYXIgdG8g YWRkcmVzcyBhIGNvbW1lbnQgZnJvbSBUb20gUGV0Y2ggcG9zdGVkIG9uIHRoZSBUQ1BNIG1haWxp bmcgbGlzdCAoc2VlDQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3RjcG0v RVF4cWtpREkxMjIyWUNEQ0hvU2NrNDBObUJvLykuIFVuZm9ydHVuYXRlbHksIHRoaXMgZ290IGxv c3Qgb24gbXkgb3duIFRPRE8gbGlzdC4NCg0KSSB0aGluayBUb20gaGFzIGNvcnJlY3RseSBwb2lu dGVkIG91dCB0aGF0IHRoaXMgZG9jdW1lbnQgY291bGQgaGF2ZSBhIGJldHRlciAoaS5lLiwgbG9u Z2VyKSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uIGluIG9yZGVyIHRvIGV4cGxhaW4gdGhlIHB1 cnBvc2UgYW5kIHRoZSBzY29wZSBvZiB0aGUgSS1ELiBUaGVyZSBpcyBhbHJlYWR5IHNvbWUgdXNl ZnVsIHJlbGF0ZWQgdGV4dCBpbiBTZWN0aW9uIDIuMS4xLCBidXQgb25lIG9yIHR3byBhZGRpdGlv bmFsIHNlbnRlbmNlcyBpbiB0aGUgYWJzdHJhY3QgYW5kL29yIGludHJvZHVjdGlvbiB3b3VsZCBw cm9iYWJseSBtYWtlIGl0IGVhc2llciB0byB1bmRlcnN0YW5kIHRoZSBvYmplY3RpdmUgb2YgdGhp cyBZQU5HIG1vZGVsLg0KDQpUaGlzIGlzIG9ubHkgYW4gZWRpdG9yaWFsIGlzc3VlIHRoYXQgbmVp dGhlciBhZmZlY3RzIHRoZSBhY3R1YWwgWUFORyBtb2RlbCBub3IgYW55IG9mIHRoZSBvdGhlciBy ZWxhdGVkIGRvY3VtZW50cy4gSSB0aGluayB0aGlzIGlzc3VlIGNhbiBlYXNpbHkgYmUgZml4ZWQg YnkgdGhlIGF1dGhvcnMgYXMgYSByZXNvbHV0aW9uIG9mIHRoZSBXR0xD4oCmDQoNClNvcnJ5IGZv ciBub3QgaGF2aW5nIGFkZHJlc3NlZCB0aGlzIGVhcmxpZXIhDQoNCk1pY2hhZWwgKGFzIGF1dGhv cikNCg0KDQpQUzogQXMgdGhpcyBpcyBhYm91dCBhIHBhc3QgY29tbWVudCBwb3N0ZWQgb24gdGhl IFRDUE0gbGlzdCwgSSBoYXZlIGFkZGVkIFRDUE0gaW4gQ0MuDQoNCg0KRnJvbTogbmV0Y29uZiA8 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFoZXNoIEpldGhhbmFuZGFu aQ0KU2VudDogRnJpZGF5LCBNYXJjaCAyNiwgMjAyMSAxMTozMSBQTQ0KVG86IG5ldGNvbmZAaWV0 Zi5vcmcNClN1YmplY3Q6IFtuZXRjb25mXSBXR0xDIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtdGNw LWNsaWVudC1zZXJ2ZXINCg0KV2UgYXJlIHN0YXJ0aW5nIGEgMiB3ZWVrIFdHTEMgZm9yIGRyYWZ0 LWlldGYtbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlciB2ZXJzaW9uIDA5Lg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtdGNwLWNsaWVudC1zZXJ2 ZXIvPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1z enRwLWNzci8+DQoNClBsZWFzZSByZXNwb25kIG9uIHRoaXMgdGhyZWFkIGluZGljYXRpbmcgeW91 ciBzdXBwb3J0IG9yIGNvbmNlcm5zIGFib3V0IHdoeSB0aGlzIGRvY3VtZW50IHNob3VsZC9zaG91 bGQgbm90IGJlIGFkb3B0ZWQuDQoNCldlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiBz dGF0ZW1lbnQgb2YgdGhlIGZvcm06DQoNCi0gSSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQg Zm91bmQgbm8gaXNzdWVzLg0KLSBJIGhhdmUgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBmb3VuZCB0 aGUgZm9sbG93aW5nIGlzc3VlcyDigKYNCg0KVGhpcyBXR0xDIHdpbGwgY29uY2x1ZGUgb24gRnJp ZGF5LCBBcHJpbCA5LiBBbiBJUFIgY2FsbCB3aWxsIGJlIGlzc3VlZCBzZXBhcmF0ZWx5Lg0KDQpU aGFuayB5b3UuDQoNCk1haGVzaCAmIEtlbnQgKGFzIGNvLWNoYWlycykNCg0KDQoNCg0KDQo= --_000_14240f263d0c4834b943353d1e9da314hsesslingende_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5I aSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhbSBhIGNvLWF1dGhvciBv ZiB0aGlzIEktRCwgc28gaWYgc29tZXRoaW5nIGlzIG1pc3NpbmcgaW4gdGhpcyBJLUQsIHRoaXMg aXMgYnkgYW5kIGxhcmdlIG15IG93biBmYXVsdOKApg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Tm9uZXRoZWxlc3MsIEkgdGhpbmsgSSBoYXZlIHByb21pc2VkIGxhc3QgeWVhciB0 byBhZGRyZXNzIGEgY29tbWVudCBmcm9tIFRvbSBQZXRjaCBwb3N0ZWQgb24gdGhlIFRDUE0gbWFp bGluZyBsaXN0IChzZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGNwbS9FUXhxa2lESTEyMjJZQ0RDSG9T Y2s0ME5tQm8vIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy90Y3BtL0VReHFraURJMTIyMllDRENIb1NjazQwTm1Cby88L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4pLg0KIFVuZm9ydHVuYXRlbHksIHRoaXMgZ290IGxvc3Qgb24gbXkgb3duIFRPRE8gbGlzdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIFRvbSBoYXMgY29ycmVjdGx5 IHBvaW50ZWQgb3V0IHRoYXQgdGhpcyBkb2N1bWVudCBjb3VsZCBoYXZlIGEgYmV0dGVyIChpLmUu LCBsb25nZXIpIGFic3RyYWN0IGFuZCBpbnRyb2R1Y3Rpb24gaW4gb3JkZXIgdG8gZXhwbGFpbiB0 aGUgcHVycG9zZSBhbmQgdGhlIHNjb3BlIG9mIHRoZSBJLUQuIFRoZXJlDQogaXMgYWxyZWFkeSBz b21lIHVzZWZ1bCByZWxhdGVkIHRleHQgaW4gU2VjdGlvbiAyLjEuMSwgYnV0IG9uZSBvciB0d28g YWRkaXRpb25hbCBzZW50ZW5jZXMgaW4gdGhlIGFic3RyYWN0IGFuZC9vciBpbnRyb2R1Y3Rpb24g d291bGQgcHJvYmFibHkgbWFrZSBpdCBlYXNpZXIgdG8gdW5kZXJzdGFuZCB0aGUgb2JqZWN0aXZl IG9mIHRoaXMgWUFORyBtb2RlbC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo aXMgaXMgb25seSBhbiBlZGl0b3JpYWwgaXNzdWUgdGhhdCBuZWl0aGVyIGFmZmVjdHMgdGhlIGFj dHVhbCBZQU5HIG1vZGVsIG5vciBhbnkgb2YgdGhlIG90aGVyIHJlbGF0ZWQgZG9jdW1lbnRzLiBJ IHRoaW5rIHRoaXMgaXNzdWUgY2FuIGVhc2lseSBiZSBmaXhlZCBieSB0aGUgYXV0aG9ycyBhcyBh IHJlc29sdXRpb24NCiBvZiB0aGUgV0dMQ+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlNvcnJ5IGZvciBub3QgaGF2aW5nIGFkZHJlc3NlZCB0aGlzIGVhcmxpZXIhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWljaGFlbCAoYXMgYXV0aG9yKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlBTOiBBcyB0aGlzIGlzIGFib3V0IGEgcGFzdCBjb21tZW50IHBvc3RlZCBvbiB0 aGUgVENQTSBsaXN0LCBJIGhhdmUgYWRkZWQgVENQTSBpbiBDQy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBuZXRjb25mICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5P biBCZWhhbGYgT2YgPC9iPk1haGVzaCBKZXRoYW5hbmRhbmk8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBNYXJjaCAyNiwgMjAyMSAxMTozMSBQTTxicj4NCjxiPlRvOjwvYj4gbmV0Y29uZkBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbbmV0Y29uZl0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1u ZXRjb25mLXRjcC1jbGllbnQtc2VydmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+V2UgYXJlIHN0YXJ0aW5nIGEgMiB3ZWVrIFdHTEMgZm9yIGRyYWZ0LWlldGYtbmV0Y29uZi10 Y3AtY2xpZW50LXNlcnZlciB2ZXJzaW9uIDA5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXN6 dHAtY3NyLyI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi10Y3AtY2xpZW50LXNlcnZlci88L3NwYW4+PC9hPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlBsZWFzZSByZXNwb25kIG9uIHRoaXMgdGhyZWFkIGluZGljYXRpbmcgeW91ciBzdXBw b3J0IG9yIGNvbmNlcm5zIGFib3V0IHdoeSB0aGlzIGRvY3VtZW50IHNob3VsZC9zaG91bGQgbm90 IGJlIGFkb3B0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5XZSBhcmUgcGFydGljdWxhcmx5IGludGVyZXN0ZWQgaW4gc3RhdGVtZW50IG9mIHRoZSBm b3JtOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBJ IGhhdmUgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBmb3VuZCBubyBpc3N1ZXMuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0gSSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBhbmQgZm91bmQgdGhl IGZvbGxvd2luZyBpc3N1ZXMg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGlzIFdHTEMgd2lsbCBjb25jbHVkZSBvbiBGcmlkYXksIEFwcmlsIDku IEFuIElQUiBjYWxsIHdpbGwgYmUgaXNzdWVkIHNlcGFyYXRlbHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1haGVzaCAmYW1wOyBLZW50 IChhcyBjby1jaGFpcnMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_14240f263d0c4834b943353d1e9da314hsesslingende_-- From nobody Wed Apr 7 06:09:19 2021 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FB53A44C5; Wed, 7 Apr 2021 06:09:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161780095374.20113.9948378570841265823@ietfa.amsl.com> Date: Wed, 07 Apr 2021 06:09:13 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-15.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 13:09:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Modules describing Capabilities for Systems and Datastore Update Notifications Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-15.txt Pages : 27 Date : 2021-04-03 Abstract: This document defines two YANG modules,"ietf-system-capabilities" and "ietf-notification-capabilities". The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG related system capabilities for servers. The module can be used to report capability information from the server at run-time or implementation- time, per the YANG Instance Data File Format. The module "ietf-notification-capabilities" augments "ietf-system- capabilities" to specify capabilities related to Subscription to YANG Notifications for Datastore Updates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-15 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 7 08:21:59 2021 Return-Path: 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 AE41B3A1D89; Wed, 7 Apr 2021 08:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BT-fqX6-jy0V; Wed, 7 Apr 2021 08:21:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA7F3A1E47; Wed, 7 Apr 2021 08:21:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 27086F407B0; Wed, 7 Apr 2021 08:21:19 -0700 (PDT) To: balazs.lengyel@ericsson.com, andy@yumaworks.com, mbj@tail-f.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: rwilton@cisco.com, iesg@ietf.org, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210407152119.27086F407B0@rfc-editor.org> Date: Wed, 7 Apr 2021 08:21:19 -0700 (PDT) Archived-At: Subject: [netconf] [Errata Rejected] RFC8341 (6493) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 15:21:54 -0000 The following errata report has been rejected for RFC8341, "Network Configuration Access Control Model". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6493 -------------------------------------- Status: Rejected Type: Technical Reported by: Balazs Lengyel Date Reported: 2021-03-24 Rejected by: Robert Wilton (IESG) Section: 3.5.2 Original Text ------------- All the same rules as an instance-identifier apply, except that predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key. Corrected Text -------------- All the same rules as an instance-identifier apply, except that predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key. Specifying prefixes for the node names is OPTIONAL. If a prefix is not specified the node-instance-identifier represents all possible server instances. Notes ----- For the typedef node-instance-identifier (and the leaf path) it is not clear whether the value should or should not include prefixes? https://tools.ietf.org/html/rfc7950#section-9.13.2 states "All node names in an instance-identifier value MUST be qualified with explicit namespace prefixes" https://tools.ietf.org/html/rfc7950#section-14 - instance-identifier rule indicates the prefixes are optional. Whichever is the correct answer it should be explicitly stated. If prefixes are optional and we have 2 leaves with the same path except the namespace/prefix I assume both are referenced (effected) by the nacm rule. Correct? Actually this is a bit misleading also in RFC7950. --VERIFIER NOTES-- The required behavior is specified via section 9.13.2 of RFC 7950. The ABNF for instance-identifier in RFC 7950 could be clearer to indicate that explicit prefixes are required, but either way the rules in section 9.13.2 of RFC 7950 for instance identifiers cannot be ignored. -------------------------------------- RFC8341 (draft-ietf-netconf-rfc6536bis-09) -------------------------------------- Title : Network Configuration Access Control Model Publication Date : March 2018 Author(s) : A. Bierman, M. Bjorklund Category : INTERNET STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Apr 9 02:58:35 2021 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1943A1ACB; Fri, 9 Apr 2021 02:58:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ladislav Lhotka via Datatracker To: Cc: draft-ietf-netconf-tcp-client-server.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161796231010.8005.7390142571009530431@ietfa.amsl.com> Reply-To: Ladislav Lhotka Date: Fri, 09 Apr 2021 02:58:30 -0700 Archived-At: Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-tcp-client-server-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 09:58:30 -0000 Reviewer: Ladislav Lhotka Review result: Ready with Issues The modules are well designed and nicely documented, both in the descriptions and text of the Internet-Draft. **** Comments - Sections 2.1.4, 3.1.3, 4.1.3: the sentence 'The "..." module does not contain any protocol-accessible nodes.' is misleading in that the modules do define data nodes that are intended to be protocol accessible after the corresponding grouping is used. I know this is a part of the NETCONF/YANG lingo, but another formulation that clearly says what's going on might be preferable. - Sections 2.2, 3.2 and 4.2: the XML snippets use document elements "tcp-common", "tcp-client" and "tcp-server", but these containers are not defined in the corresponding modules. This is confusing, my suggestion is to rewrite the examples in the JSON representation where no such top-level node is necessary. - What is the purpose of "tcp-connection-grouping" if it only uses "tcp-common-grouping" and nothing else? Why cannot "tcp-common-grouping" be used directly? - The "local-port" parameter defined in ietf-tcp-client seems dubious from the security viewpoint in that fixing the source port makes it easier for attackers to steal the connection (see RFC 6056). If the feature "local-binding-supported" is needed at all, I'd suggest to mention this in Security Considerations. - The module ietf-tcp-client uses the placeholder "RFC AAAA", which is not defined in the Editorial Note. **** Nits - RFC 7950 is cited repeatedly (6 times) in a general context, e.g. whenever YANG 1.1 is mentioned. It should suffice to use the citation at the first appearance. - sec. 1.3: s/in compliant/is compliant/ - in 3 places: s/illustatrating/illustrating/ From nobody Mon Apr 12 01:19:29 2021 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886F83A11A9; Mon, 12 Apr 2021 01:19:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ladislav Lhotka via Datatracker To: Cc: draft-ietf-netconf-http-client-server.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161821556350.10432.14910369341748800490@ietfa.amsl.com> Reply-To: Ladislav Lhotka Date: Mon, 12 Apr 2021 01:19:23 -0700 Archived-At: Subject: [netconf] Yangdoctors last call review of draft-ietf-netconf-http-client-server-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 08:19:24 -0000 Reviewer: Ladislav Lhotka Review result: Ready with Nits The document defines two YANG modules - ietf-http-client and ietf-http-server - that belong to a relatively complex set of modules. The modules are well designed and nicely documented, both in the descriptions and document text. **** Comments - Sections 2.1.3 and 3.1.3: the sentence 'The "..." module does not contain any protocol-accessible nodes.' is misleading in that the modules do define data nodes that are intended to be protocol accessible after the corresponding grouping is used. I know this is a part of the NETCONF/YANG lingo, but another formulation that clearly says what's going on might be preferable. - Sections 2.2 and 3.2: the XML snippets use document elements "http-client" and "http-server", but these containers are not defined in the corresponding modules. This is confusing, my suggestion is to rewrite the examples in the JSON representation where no such top-level node is necessary. - Placeholders BBBB, CCCC and EEEE are defined in Editorial Note but never used **** Nits - RFC 7950 is cited repeatedly (4 times) in a general context, e.g. whenever YANG 1.1 is mentioned. It should suffice to use the citation at the first appearance. From nobody Tue Apr 13 01:43:36 2021 Return-Path: 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 4C4643A0C05 for ; Tue, 13 Apr 2021 01:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 YTouDc7q1Y4w for ; Tue, 13 Apr 2021 01:43:29 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C3E3A0C07 for ; Tue, 13 Apr 2021 01:43:29 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id r5so5277499ilb.2 for ; Tue, 13 Apr 2021 01:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rLJBSjgdRX6KsoGNZHSbAftIVOnEq9nGrQ6E1mhGZsk=; b=MQOa13ZfX4T6ExAt9vlznVcesLiM3u7aDeNgiEHhnDcm7OBrrmjm+AfseE/lpWDcJR YUCp+uRICs3ikg4xygz5mAVcWW/l67q9mlHD9DGyGXn0o/wp+5cYlGzb5zrC2JcAtMSn 2lFBhmat7irgS6ysghIe58ai7VN2/isayajWRotts14FxuhMgLgWr0i+pfMTSuGzwVin vyippo3HGebHzF6FWxOqTEp65YfJNvyGpTBhGjzuBNiG7yerSurUufM3p3izW45xd2Hj OAHtDea56XgH2CYCf6LNnqSo8Iy/clbk75hDxB/L8U8PEOcEt5V8xa98KMW+KV4GJ/MV Ni0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rLJBSjgdRX6KsoGNZHSbAftIVOnEq9nGrQ6E1mhGZsk=; b=a9+XuzVxvffKTyXYkonzCw92voBm9+cMS/rUkKitKaLB+1DVtHsmySYR2ss4BjTYbD P9eW32/9wXbDXV2EHdWjsWJo4nJCOYCPXSWw31NeNGdJ9CV9FSrlGF3I3tRtGp9/yDet PFQgpmIL1ClNybgYSR5CRP3N2LTNxx99e2cnkpq67zY/ju5HRbEsybvP0A1AXZWxR897 +/zAKljv/jYZv2W9lMOX7g5I1Dp3fbyoiy8z+dznNjVrJQ/EmlPixYnNr3EQpZLLAuR0 r8nef8uJr9Ai8b6BN+9Zp2UNbFBt4XQwMRxvBOuGOzwV0YWZD8r8y6roOONM+Y/hXj3v it6Q== X-Gm-Message-State: AOAM5320gfrIwLCzkGQr3Oj7KAOnh3rajXPYYNKcXr5BiTLJZ86XexFQ sNFr2fM2HmGb3wfdKFu8RINeGrG1v4kPaFROVY4= X-Google-Smtp-Source: ABdhPJyHWNCNZU5WfJyXkj2lPB7oiA42UZG2KxDQ1kUNSwL+k+UZxgXlb3mdkDvimRpgeym/73lDnbyG1S6QMlaU+as= X-Received: by 2002:a05:6e02:20c5:: with SMTP id 5mr9289277ilq.14.1618303407792; Tue, 13 Apr 2021 01:43:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Tue, 13 Apr 2021 14:12:51 +0530 Message-ID: To: Mahesh Jethanandani Cc: netconf@ietf.org Content-Type: multipart/alternative; boundary="000000000000c2af7e05bfd69f2b" Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-tls-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 08:43:34 -0000 --000000000000c2af7e05bfd69f2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mahesh, WG, I have reviewed the draft. The PCE YANG uses these groupings and I am happy to see the WG make progress on this I-D. Few comments - - Both abstract and introduction say that the first module is the TLS client whereas the first module defined in this I-D is the TLS common. - I am wondering if anything needs to be done for the older versions of TLS which are made historic. The use of features helps, is there any other guidance that needs to be given? - Why is there no identity for TLS 1.3? - For the feature tls-1_3, the description says 1.2 - Copyright year in the YANG modules is still 2020 - Authors in the YANG module is inconsistent with the I-D - Reference used in YANG (FIPS PUB 180-4) needs to be added in the I-D as well. Thanks! Dhruv On Sat, Mar 27, 2021 at 4:01 AM Mahesh Jethanandani wrote: > > We are starting a 2 week WGLC for draft-ietf-netconf-tls-client-server > version 23. > > https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ > > > Please respond on this thread indicating your support or concerns about > why this document should/should not be adopted. > > We are particularly interested in statement of the form: > > - I have reviewed the draft and found no issues. > - I have reviewed the draft and found the following issues =E2=80=A6 > > This WGLC will conclude on Friday, April 9. An IPR call will be issued > separately. > > Thank you. > > Mahesh & Kent (as co-chairs) > > > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000c2af7e05bfd69f2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mahesh, WG,

I have reviewed the draft. The PCE YANG = uses these groupings and I am happy to see the WG make progress on this I-D= .

Few comments -
- Both abstract and introduction say that the fi= rst module is the TLS client whereas the first module defined in this I-D i= s the TLS common.
- I am wondering if anything needs to be done for the = older versions of TLS which are made historic. The use of features helps, i= s there any other guidance that needs to be given?
- Why is there no ide= ntity for TLS 1.3?
- For the feature tls-1_3, the description says 1.2- Copyright year in the YANG modules is still 2020
- Authors in the YA= NG module is inconsistent with the I-D
- Reference used in YANG (FIPS PU= B 180-4) needs to be added in the I-D as well.

Thanks!
Dhruv

On Sat, Mar 27, 2021 at 4:01 AM Mahesh Jethanandani <mjethanandani@gmail.com> wro= te:

We are starting a 2 week WGLC for draft-ietf-netco= nf-tls-client-server version 23.

<= div>
Please respond on this thread indicating your support or= concerns about why this document should/should not be adopted.
<= br>
We are particularly interested in statement of the form:

- I have reviewed the draft and found no issues.=C2=A0=
- I have reviewed the draft and found the following issues =E2= =80=A6

This WGLC will conclude on Friday, April 9.= An IPR call will be issued separately.

Thank you.=

Mahesh & Kent (as co-chair= s)






_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000c2af7e05bfd69f2b-- From nobody Tue Apr 13 04:43:56 2021 Return-Path: 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 26C2A3A116A; Tue, 13 Apr 2021 04:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, 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=hq.sk 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 LQY23kYyUV5T; Tue, 13 Apr 2021 04:43:44 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF193A1166; Tue, 13 Apr 2021 04:43:44 -0700 (PDT) Received: from nitebug.nitenet.local (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 31F0A245135; Tue, 13 Apr 2021 13:43:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1618314219; bh=XwdX1JJxfjoOCwVXlWEens2Yu5qpa8AoJfYDK6hH5Fw=; h=To:References:From:Subject:Date:In-Reply-To; b=Y6cE2Xlcwnh6ziZ859s5XuFwL0JlFPnomWB3LRBgGNh4Aiqal8y6IluCEGnGaue2d j8E7/WqS5m+ZogOzMv2dtvzkffi3dTuds5EuRL2XZWzpXPIK2RmRW21tnCyy07Uf2I Pv/mYkqiUeykhlxawlpIm4C/CHKjQKKjCvDnJ0QU= To: =?UTF-8?Q?Michal_Va=c5=a1ko?= , Andy Bierman , "Eric Voit (evoit)" , netconf , netmod References: <52f2-606b1d80-d-7afd9d00@152658395> <87wntf3nca.fsf@nic.cz> From: Robert Varga Message-ID: <44da4ec9-da0e-ba39-eda1-b785b0f8d478@hq.sk> Date: Tue, 13 Apr 2021 13:43:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87wntf3nca.fsf@nic.cz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL" Archived-At: Subject: Re: [netconf] [netmod] YANG Push module errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 11:43:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL Content-Type: multipart/mixed; boundary="0By5s5AUaQ2ivcKUEPiLh3fQvCht8151F"; protected-headers="v1" From: Robert Varga To: =?UTF-8?Q?Michal_Va=c5=a1ko?= , Andy Bierman , "Eric Voit (evoit)" , netconf , netmod Message-ID: <44da4ec9-da0e-ba39-eda1-b785b0f8d478@hq.sk> Subject: Re: [netmod] [netconf] YANG Push module errors References: <52f2-606b1d80-d-7afd9d00@152658395> <87wntf3nca.fsf@nic.cz> In-Reply-To: <87wntf3nca.fsf@nic.cz> --0By5s5AUaQ2ivcKUEPiLh3fQvCht8151F Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/04/2021 09:04, Ladislav Lhotka wrote: >> I see. Okay, thanks for the clarification and yes, if this was explici= tly mentioned in the RFC it would be great. Although, the validity of you= r example was not in question. Rather something like: >> >> container foo { >> if-feature X; >> container bar; >> } >> >> augment /foo/bar { >> container Y; >> } >> >> I am just going to assume this is what you meant and simply that the r= equirement is that any schema path must point to an existing schema node,= ignoring any "if-feature" statements. > I think it also depends on whether features are set before or after pro= cessing the modules. In the former case, an augment statement with an eff= ectively missing target node can IMO be silently ignored, without even pa= rsing its contents. This very case has been discussed here: https://mailarchive.ietf.org/arch/msg/netmod/Icd5c8J27P3UKjloNG8VC9fApoM/= FTR the original request for OpenDaylight lives here: https://jira.opendaylight.org/browse/YANGTOOLS-859 and it provides some additional context. As an implementation author, I certainly did not like the implications of the request, but Andy brought up a very important point in that thread= : > The modules are valid. > The conformance decision (i.e., which features are advertised and which= are > not by a server implementation) > does not change the compile-time validity of the YANG modules i.e. even if the YANG modules are being interpreted as part of assembling a server implementation, if-feature processing phase comes only after cross-statement relationships have been established and therefore the augment is valid, but 'container Y' disappears just as 'container bar' does. This is further reinforced by Martin's response in this (related) thread: https://mailarchive.ietf.org/arch/msg/netmod/9JgPZphOdim-wLZA3NrSe3I1un4/= Regards, Robert --0By5s5AUaQ2ivcKUEPiLh3fQvCht8151F-- --excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE9xJg9S8sgC+6qlK6U310SwoeP0UFAmB1g+oFAwAAAAAACgkQU310SwoeP0XJ 8xAAlwqTYFWd/JXqbx//UPLGE+/Q0OnFDbk+UVZAYQf7ZDVl8Chb87Ft9i87n+twQQbcFROCBT3O fYMVDHiM9Jm95pCc+gYwK3Nv5F0LFtqPcEd22C9H/ehc+5K/hu44KE+VBo4IpF0EKKML892gj8lK rL58Mo7MhBsu5a1O8SeWLsZWMa/e99pUU7Alkb1rzW7UisA3c6Vd2h9Z6crhzz+RBWQkuu898TAU DlXrAO5FWR34juRu6krh4hKBqj5xb5ylS/gTGcoj0rYFawLF7V/EPr7yPRsRR74m770NG1K2rXTR ndqIE/8hYojVJ4Y1Qn5oxd9MuBD6Y8Mlfcr8FBZEMkds9AOxFKqne1pU9D/ONUzulU7A/DENRjnY MM/FTBz6WFuwUB0M9GHMsNI5Hha/dPEC23r8PFGZKwDRxjhp7J9SIl+LlakB1v9vpajmCLFKZ726 622LoVr+CeAczLbPAneL8LyOiPozsVP4uqac6F0J3W3K/NhKDKc9KZRrcqsVivdBXhUrx2hwNHGx ThwRV/ebxyrKFwQ8FIA9tCwpYKfP9lFvOfUB9y7DDuZ6zY0AWKbrPPI1mbCz3pO08bOxIsTMefA+ lB8scvhmvp425WRqlyXk3NtsMIfDpZqSpPf4t7MzSjSGOnABBGGBsOhLDw613R4FUX/ehQCbQMtS n40= =HAPX -----END PGP SIGNATURE----- --excyv2uMZZv8rGFLx1lMLA2Y7VNZcxZWL-- From nobody Wed Apr 14 17:55:13 2021 Return-Path: <01000178d3063b0c-963bb741-e8e6-41bc-821e-bb25b421ed26-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 0E34D3A26EC for ; Wed, 14 Apr 2021 17:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 UcNiin81p-NM for ; Wed, 14 Apr 2021 17:55:05 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C043A26E9 for ; Wed, 14 Apr 2021 17:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618448104; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=+rZw9eInSWL4o013+mevjk0Dx91dWcfIiOOTt+FOu6Q=; b=Nc7npE9MDK3tQohoPdfUgb33CNWwUgQMyRXuHGGqaxyh3M5bh6Usd1hz3fyIr2aZ scwNq1fBzvbWRDJ5u8F3DG9LGY1rJV1k5K/w3kI46yIiVDvFA98ClhGc+gup8G/Nv11 dPnGbk4DypJh57auYQ/HmDxxOSbX/1LpdpswsBPU= From: Kent Watsen Message-ID: <01000178d3063b0c-963bb741-e8e6-41bc-821e-bb25b421ed26-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_218B0FB2-0DFC-4938-8251-27A8C485A47D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 15 Apr 2021 00:55:04 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Benoit References: <172a3cd6-dd95-c535-23d0-ffbd879d6319@claise.be> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.15-54.240.8.31 Archived-At: Subject: Re: [netconf] Shepherd review of draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 00:55:11 -0000 --Apple-Mail=_218B0FB2-0DFC-4938-8251-27A8C485A47D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [CC NETCONF] K. > On Apr 14, 2021, at 8:27 PM, Kent Watsen wrote: >=20 > Hi Benoit (and Balazs), >=20 > The text-formatting below is pretty garbled, but we=E2=80=99re almost = done and it=E2=80=99s almost understandable ;) >=20 > Please see more comments below. >=20 > K. >=20 >=20 >> On Apr 7, 2021, at 9:44 AM, Benoit > wrote: >>=20 >> btw, a mistake with the year 22021 has been corrected in my temp 016 = version. >=20 > Good catch! :) >=20 >=20 >> Regards, Benoit >>> Hi Kent, >>>=20 >>> The draft has been posted. >>>=20 >>> Regards, Benoit >>>=20 >>>=20 >>> -------- Forwarded Message -------- >>> Subject: Re: [netconf] Shepherd review of = draft-ietf-netconf-notification-capabilities >>> Date: Fri, 2 Apr 2021 21:58:43 +0200 >>> From: Benoit >>> To: Kent Watsen = , Benoit = >>> CC: netconf@ietf.org = >>>=20 >>> Hi Kent, >>>=20 >>> Removed what's agreed upon. >>> See inline. >>>=20 >>>> Balazs and Benoit, >>>>=20 >>>> Thanks for the update and the response. B Please see below for = followups. >>>>=20 >>>> K. B // shepherd >>>>=20 >>>>=20 >>>>> On Feb 22, 2021, at 4:20 PM, Benoit > wrote: >>>>>=20 >>>>> Hi Kent, >>>>>=20 >>>>> Sorry it took us so long to update the draft. >>>>> Below are our answer. We believe we have addressed all comments. >>>>=20 >>>>=20 >>>>> - s/YANG Instance Data/YANG Instance Data = (I-D.ietf-netmod-yang-instance-file-format)/ >>>>> BALAZS: OK >>>>=20 >>>> Hmmm, now itb paragraph, but still without a reference. B = Admittedly, I think references in Abstracts are discouraged but, as it = stands, readers may be confused. B Note that searching for "YANG = Instance Data File Formatb other matching because only other matching = string is in the b B If you donb import the term in the b >>> Done.=20 >>> Added to the terminology section: >>> B B B B B B B B B The terms "YANG instance data file format", = "instance data", and=20 >>> B B B B B B B B B B "instance data set" are used as defined in=20 >>> B B B B B B B B B . >=20 > WFM >=20 >=20 >>>>=20 >>>>=20 >>>>> - s/"Subscription to YANG Datastores" (YANG-Push)/Subscription >>>>> to YANG Notifications for Datastore Updates (RFC 8641)/ >>>>> BALAZS: OK >>>>=20 >>>> Thanks, but now that sentence ends 'augmentingB the = "ietf-system-capabilitiesb should either be 'augmenting = "ietf-system-capabilitiesb "ietf-system-capabilitiesb >>>>=20 >>>>=20 >>> Done. 'augmenting "ietf-system-capabilitiesb >>>>=20 >>>>> - Actually (in ref to the above two comments), the sentence = structure in p2 seems >>>>> backwards. Better would be to say "The module can be used to = report capability >>>>> information from the server at run-time or implementation-time, = per I-D.ietf-netmod-yang-instance-file-format.b class=3D""> BENOIT: = idnits complains when we have references in the abstract. Removed the = references=20 >>>>=20 >>>> Ah, yes, right, then import the term? >>>=20 >>> See above. Added to the terminology section: >>>>=20 >>>>> - s/that can be used to specify/that can be used to discover (as = read-only operational state)/ >>>>> BENOIT: DONE >>>>=20 >>>> Good, but searching for =E2=80=9Chat can be used to specifyb = resulted in finding two other instances that I believe would benefit = from the same update. >>> Only one was left, in the abstract. Now changed. >>> Note that I did not add "(as read-only operational state)" in the = abstract. I left for the explanation in the draft. I'm fear that might = be distracting and confusing. >=20 > Fine. >=20 >=20 >>>>=20 >>>>=20 >>>>> - rather than have the b class=3D""> point for system level = capabilitiesb an empty >>>>> b statement? >>>>> BALAZS: choice would not be a good solution because it would only = allow one set of capabilities, while our goal is to allow different = capability set side by side. >>>>=20 >>>> You misunderstand. B Adding an empty choice preserves the data = model as is. B Itb you have: >>>>=20 >>>> OLD: >>>> B B //B augmentation point for system level capabilities >>>>=20 >>>> NEW: >>>> B B choice system-capabilities { >>>> B B B // mandatory true; B // must at least one exist? >>>> B B B descriptionB=20 >>>> B B B B B "augmentation point for system level capabilities.b >>>> B B } >>>>=20 >>> In our opinion,B the choice is not an ideal solution. For the choice = you may only select one case. We, on the other hand, want to allow = multiple augmentations to be used at the same time. If we used a choice, = we could not allow multiple different cases/augmentations to be used at = the same time. It is a question of on-of-many versus any-number. >=20 > Okay. >=20 >=20 >>>>> - rather than have the b class=3D""> augmentation point for = datastore or data node level capabilitiesb why not have an empty b same >>>>> description statement? >>>>> BALAZS: see above. >>>>=20 >>>> Also see above B ;) >>> Also see above ;) >>>>=20 >>>>=20 >>>>> - is the comment "The special value '/' denotes all data nodes in = the >>>>> datastore.b consistent with XPath 1.0 expressions. >>>>> BALAZS: we are consistent witjh the NACM RFC, which says: >>>>> B B B B B B B B B B B B B B B B B B B The special value '/' refers = to all possible >>>>> B B B B B B B B B B B B B B B B B B B datastore contents."; >>>>=20 >>>> Then the comment should say b Section ???, the special valueb >>> Done. >>> B B B B B B B B B leaf node-selector { >>> B B B B B B B B B B B type nacm:node-instance-identifier; >>> B B B B B B B B B B B description >>> B B B B B B B B B B B B B "Selects the data nodes for which = capabilities are >>> B B B B B B B B B B B B B B specified. The special value '/' denotes = all data nodes >>> B B B B B B B B B B B B B B in the datastore, as specified in path = YANG object in=20 >>> B B B B B B B B B B B B B B data definition statement [RFC8341]; >>> B B B B B B B B B B B reference >>> B B B B B B B B B B B B B B B "RFC 8341: Network Configuration = Access Control Model"; >>> B B B B B B B B B } >=20 > Looking at the new draft, I see the added clarification (thanks), but = it=E2=80=99s a bit difficult to read. Would this help? >=20 > OLD: as specified in path YANG object in data definition statement = [RFC8341] >=20 > NEW: consistent with the =E2=80=9Cpath=E2=80=9D leaf node on page 41 = in [RFC8341]. >=20 >=20 >=20 >>>>> - this command detected an issue: pyang --ietf = ietf-system-capabilities\@2020-03-23.yang. >>>>> (Ib block in the module >>> $ pyang --ietf ietf-system-capabilities.yang >>> $=20 >>> $ pyang -v=20 >>> pyang 2.4.0 >>>=20 >>>>> b class=3D""> text directly from `pyang --ietf-help`. >>>>=20 >>>> No response? >>> That was an oversight. Done. >=20 > Thanks. >=20 >=20 >>>>> - this command detected a number of issues: pyang -f yang = --keep-comments --yang-line-length 69 = ietf-notification-capabilities\@2020-03-23.yang > tmp; diff = ietf-notification-capabilities\@2020-03-23.yang tmp. (whitespace at end = of lines) >>>>=20 >>>> No response? >>> That was an oversight. Done for both modules >=20 > Thanks, but be mindful that tool=E2=80=99s opinion is not always = perfect and that discretion can override it where preferred. The = primary intent is to show that an effort was made... >=20 > In particular, the closing =E2=80=9C; for the "import = ietf-yang-library=E2=80=9D statement is on a line by itself. IDK if the = tool is suggesting this, but I think it better if the closing =E2=80=9C; = were brought up to the previous line. >=20 >=20 >=20 >>>>> - through draft (in both body and YANG modules), bracket datastore = names with >>>>> angle brackets (e.g., s/running//) wherever the datastore = name is NOT >>>>> followed by word b name is NOT followed by the >>>>> word b quotes, where it makes sense >>>>> to do so. BTW, I note the none of the datastore names are imported = as terms or >>>>> otherwise introduced where first used... >>>>> Benoit: Done >>>>=20 >>>> I donb >>> What I did in the previous draft version: I searched for all = instances of running, and it's always followed by the word datastore. I = did the same for candidate, operational (there are no instances of = startup and intended). >>> I double-checked this new version too. >>>=20 >>> Added a reference to RFC 8342 with the first occurrence of datastore = in the intro. >=20 > Thanks. >=20 >=20 >=20 >>>>> - the YANG Doctor review suggested adding comments regarding >>>>> if imports needed to be implemented. I see such comments were >>>>> added in -06 but theyb removed. I strongly >>>>> second Ladab Library >>>>> instance somewhere, not only to document which modules need to be = implemented, but also to document the totality of them, as I >>>>> was unpleasantly surprised by how many there were (12 in total!) >>>>> BALAZS: OK, Included for the 3 imports that need implemented. They = were removed due to comments, but I like the sentences. >>>>=20 >>>> Better, but no YANG Library instance? B Oh well. >>>=20 >>> Thanks for your review. >>>=20 >>> I'll be posting a new version soon. >=20 > No problem, thanks. >=20 > K. >=20 >=20 >>> Regards, Balazs and Benoit --Apple-Mail=_218B0FB2-0DFC-4938-8251-27A8C485A47D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [CC = NETCONF]

K.


On Apr 14, 2021, at 8:27 PM, Kent Watsen = <kent+ietf@watsen.net> wrote:

Hi Benoit (and Balazs),

The text-formatting below is = pretty garbled, but we=E2=80=99re almost done and it=E2=80=99s almost understandable = ;)

Please see more comments = below.

K.


On Apr 7, 2021, at 9:44 AM, = Benoit <benoit@claise.be> wrote:

btw, a mistake with the year 22021 has been = corrected in my temp 016 version.

Good catch!  :)


Regards, = Benoit
Hi Kent,

The draft = has been posted.

Regards, Benoit


-------- Forwarded Message --------

Hi = Kent,

Removed what's agreed upon.
See inline.

Balazs and Benoit,

Thanks for the update and the response. = B Please see below for followups.

K. B // shepherd

On Feb 22, 2021, at 4:20 PM, Benoit <benoit@claise.be> wrote:

Hi = Kent,

Sorry it took us so long to update = the draft.
Below are our answer. We believe we have = addressed all comments.


- s/YANG Instance Data/YANG Instance = Data (I-D.ietf-netmod-yang-instance-file-format)/
BALAZS: = OK

Hmmm, now itb paragraph, but still = without a reference. B Admittedly, I think references in Abstracts are = discouraged but, as it stands, readers may be confused. B Note that = searching for "YANG Instance Data File Formatb other matching because = only other matching string is in the b B If you donb import the term in = the b
Done. 
Added to the = terminology section:
B B B B B B B B B The terms "YANG = instance data file format", "instance data", and 
B B B B B B = B B B B "instance data set" are used as defined in 
B B B B B B = B B B <xref = target=3D"I-D.ietf-netmod-yang-instance-file-format"/>.

WFM




- s/"Subscription to YANG Datastores" = (YANG-Push)/Subscription
to YANG Notifications for = Datastore Updates (RFC 8641)/
BALAZS: OK

Thanks, but now that sentence ends = 'augmentingB the "ietf-system-capabilitiesb should either be 'augmenting = "ietf-system-capabilitiesb "ietf-system-capabilitiesb


Done. = 'augmenting "ietf-system-capabilitiesb
- Actually (in ref to the above two = comments), the sentence structure in p2 seems
backwards. = Better would be to say "The module can be used to report capability
information from the server at run-time or = implementation-time, per I-D.ietf-netmod-yang-instance-file-format.b = class=3D""> BENOIT: idnits complains when we have references in the = abstract. Removed the references 

Ah, yes, right, then import the = term?

See above. Added to the = terminology section:

- s/that can be used to = specify/that can be used to discover (as read-only operational = state)/
BENOIT: DONE

Good, but searching for =E2=80=9Chat = can be used to specifyb resulted in finding two other instances that I = believe would benefit from the same = update.
Only one was left, in the = abstract. Now changed.
Note that I did not add "(as = read-only operational state)" in the abstract. I left for the = explanation in the draft. I'm fear that might be distracting and = confusing.

Fine.




- rather = than have the b class=3D""> point for system level capabilitiesb an = empty
b statement?
BALAZS: choice would not = be a good solution because it would only allow one set of capabilities, = while our goal is to allow different capability set side by side.

You misunderstand. B Adding an empty choice preserves = the data model as is. B Itb you have:

OLD:
B B //B augmentation point for system level = capabilities

NEW:
B B choice system-capabilities = {
B B B // mandatory true; B // must at least one = exist?
B B B descriptionB 
B B B = B B "augmentation point for system level capabilities.b
B = B }

In our opinion,B = the choice is not an ideal solution. For the choice you may only select = one case. We, on the other hand, want to allow multiple augmentations to = be used at the same time. If we used a choice, we could not allow = multiple different cases/augmentations to be used at the same time. It = is a question of on-of-many versus any-number.

Okay.


- rather than have the b class=3D""> = augmentation point for datastore or data node level capabilitiesb why = not have an empty b same
description statement?
BALAZS: see above.

Also see above B ;)
Also see = above ;)


- is the comment "The special value '/' = denotes all data nodes in the
datastore.b consistent with = XPath 1.0 expressions.
BALAZS: we are consistent witjh the = NACM RFC, which says:
B B B B B B B B B B B B B B B B B B = B The special value '/' refers to all possible
B B B B B B = B B B B B B B B B B B B B datastore contents.";

Then the comment should say b Section = ???, the special valueb
Done.
B B B B B B B B B leaf node-selector {
B B B B = B B B B B B B type nacm:node-instance-identifier;
B B B B = B B B B B B B description
B B B B B B B B B B B B B = "Selects the data nodes for which capabilities are
B B B B = B B B B B B B B B B specified. The special value '/' denotes all data = nodes
B B B B B B B B B B B B B B in the datastore, as = specified in path YANG object in 
B B B B B B = B B B B B B B B data definition statement [RFC8341];
B B B = B B B B B B B B reference
B B B B B B B B B B B B B B B = "RFC 8341: Network Configuration Access Control Model";
B = B B B B B B B B }

Looking at the new = draft, I see the added clarification (thanks), but it=E2=80=99s a bit = difficult to read.  Would this help?

OLD: as specified in path YANG = object in data definition statement [RFC8341]

NEW: consistent with the = =E2=80=9Cpath=E2=80=9D leaf node on page 41 = in [RFC8341].



- this command detected an issue: pyang = --ietf ietf-system-capabilities\@2020-03-23.yang.
(Ib = block in the = module
$ pyang = --ietf ietf-system-capabilities.yang
$ 
$ pyang = -v 
pyang = 2.4.0

b class=3D""> text directly from = `pyang --ietf-help`.

No = response?
That was an oversight. = Done.

Thanks.


- this = command detected a number of issues: pyang -f yang --keep-comments = --yang-line-length 69 ietf-notification-capabilities\@2020-03-23.yang = > tmp; diff ietf-notification-capabilities\@2020-03-23.yang tmp. = (whitespace at end of lines)

No = response?
That was an = oversight. Done for both = modules

Thanks, but be mindful that tool=E2=80=99= s opinion is not always perfect and that discretion can override it = where preferred.  The primary intent is to show that an effort was = made...

In = particular, the closing =E2=80=9C; for the "import ietf-yang-library=E2=80= =9D statement is on a line by itself.  IDK if the tool is = suggesting this, but I think it better if the closing =E2=80=9C; were = brought up to the previous line.



- through draft (in both body and YANG = modules), bracket datastore names with
angle brackets = (e.g., s/running/<running>/) wherever the datastore name is NOT
followed by word b name is NOT followed by the
word b quotes, where it makes sense
to do so. = BTW, I note the none of the datastore names are imported as terms or
otherwise introduced where first used...
Benoit: = Done

I = donb
What I did in the previous draft = version: I searched for all instances of running, and it's always = followed by the word datastore. I did the same for candidate, = operational (there are no instances of startup and intended).
I double-checked this new version too.

Added a reference to RFC 8342 with the first occurrence of = datastore in the intro.

Thanks.



- the YANG Doctor review suggested = adding comments regarding
if imports needed to be = implemented. I see such comments were
added in -06 but = theyb removed. I strongly
second Ladab Library
instance somewhere, not only to document which modules need = to be implemented, but also to document the totality of them, as I
was unpleasantly surprised by how many there were (12 in = total!)
BALAZS: OK, Included for the 3 imports that need = implemented. They were removed due to comments, but I like the = sentences.

Better, but no YANG Library instance? B = Oh well.

Thanks for your = review.

I'll be posting a new version = soon.

No problem, thanks.

K.


Regards, Balazs and = Benoit

= --Apple-Mail=_218B0FB2-0DFC-4938-8251-27A8C485A47D-- From nobody Fri Apr 16 04:50:16 2021 Return-Path: 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 2A7023A22A9; Fri, 16 Apr 2021 04:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 jPOkD5poujDR; Fri, 16 Apr 2021 04:50:10 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80043.outbound.protection.outlook.com [40.107.8.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111223A22A5; Fri, 16 Apr 2021 04:50:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ACsokFzmhfBxYgaE2KCeLm2pytlBqfy/mSc0WsOt+X4L6t8jqnSw9Gq3GO/dX94WohR+XtRT6ZRDwz/xzh+tq4f34oLSpUwPJnG/HjZmIsnXM6lOvDPu/+p6yqErDdMEkrnK9Ha7xhDIhs0f/GppANgMOqK6rrq9AnNmWkQmkl3qaBe/OM+V/N7wrUWXW3xCCCqnbobq/cGcW1lMzC/PAl5mN1Hlt9gjSoZxB7T5bmBm7AtPl2wVTmz/qq5e+5l3qTEjYq7O98G/9wul6/8pQw0DdKZ70JcSFt3NjUyWcAWFsx5aHp/QNG7qkDdyrWe0tGj42YiFkuZHTbi5CW0fHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pa9O0ByLX1Y1vGIdOGjKQnuqSplt7mbl7OkDQQSxBz0=; b=AUKFFu/IJQT7qDsel+LFwMm7C43OenfI1SXeC79yX8pZgTvKINBS7wRF1bU2UdBsr6jkpZW254/sulmKixZ6faFZGduoZC1AP91qNXPRALVRK312nrU1dZc9llLarkOD6l91TJDZHGHobKn1zOMPLVPfjq5+RfEa0R7e72biFbeE02ozbsfCnDq20EBp8PkPXn2zkih4dTTeZCh9pg7cxY8pW4wlgjdrFCNT2T6sw+WKkY5pmXaVFmCZDmODiwx0ckd0LpC6rrfh9setaG1bGyIj4i7+b6HLrnZYfm9VoL0oGtU8PhbNIqh0vYMp/GROAd6loRpjaz0pe7Y1IVDv5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pa9O0ByLX1Y1vGIdOGjKQnuqSplt7mbl7OkDQQSxBz0=; b=a4v8AK0lF9i3VfyT4Ursf6iAiZYbCCgllmvCgWGOG4rf+PkY75YH7z3dTPPe2XrY6PolGBRZ0easGiWHXSqYpYxvFYdU6xbwpnjM2UNM9uJTVwBC3AxlqLApKVLhusGuHdL699bCi+Qjuu0e56n1jGIvst6dyi1q0kU3gqW63pk= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0065.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:62::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Fri, 16 Apr 2021 11:50:07 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.019; Fri, 16 Apr 2021 11:50:07 +0000 Date: Fri, 16 Apr 2021 13:50:04 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: "netconf@ietf.org" , YANG Doctors Message-ID: <20210416115004.fqhitq6jofc6vjih@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" , YANG Doctors References: <161045360252.14510.16755799701987783827@ietfa.amsl.com> <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR0P264CA0188.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1c::32) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0188.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1c::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Fri, 16 Apr 2021 11:50:07 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 32b91ad8-525c-44d1-bdf4-08d900cdc7d9 X-MS-TrafficTypeDiagnostic: AM4P190MB0065: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KTuBBLrsQbxL8j3J0+SPkbQCMENl6FzBS1KWJss+TBVf2HNH+JPwX1UYqfepJFLHYQ36cYvEZBwxqyfkxRsjG/WgJeD6f9u7/CkOj/SNLbf2bCR0+yehpY7E106NyrXDlQmcKCiQGcPwE1VNnvY1ETxuJmV6RotGN1HZ39mNpQ8WNZZelgbqAQf/9XT4wVuv9oW2fFt8N4o5wL7zYAtfnpCcUpDGW9z2ZAkQGFF+rytJU3K9VD1EkEjcSGd4GEz/8KE8Xf6c80qQMfOcVguMcg43kXoXTR4oZXjKyJhsemoLO9QCjQjEFAjWxZMf+E9V9P+8YnjQfc6iLrYUZKg3kdg+rw9i7UVIQ9hT4Hhr4Tk9k334kyCP+QrVqFu9S9tHfarjeS/Ug7ftTsQdnR4mMe3xzAvbaIMs8H5ESq4B3BYekd/leTErfZNA7d5R61/HbkFMyZPjWrPVs+ILfbC+gOKaLYyS+YsjAOA8KHRb06D6FZGrrD6thAHKiZ2Lp2riyxqFRbV21N6szTF8kBvOxCT/hOzVXDXTeXSAmzcfDYamfb11JWeT10z3c6GZS+TnQKsV4pb/4c6/KGfgEBt3A2SaMBAMZwuK6Gg+4vJd0vsSqUWPPlClc1rT3CJKu03WJlSSiSvoEfRtvkaPs+/UMLkJ2RdxLAQL5Ed2Cxc1IqEKT4mJscqGVFF2o5c5WmJrzLyaqzuNSZc3ZZ0aJT048C+6nhJhJtjLw7J2cwa+mfjxM6CZMk/XbBcPdB6DZQFX X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(39850400004)(346002)(136003)(366004)(396003)(54906003)(6666004)(786003)(316002)(66946007)(66556008)(86362001)(5660300002)(8676002)(8936002)(38100700002)(38350700002)(1076003)(478600001)(66476007)(52116002)(3450700001)(4326008)(956004)(16526019)(186003)(6496006)(6486002)(2906002)(83380400001)(26005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?NjhBYWloc0wySDBnWUdyNloxaHNLcFFlbDcvODBUZkRyS0VKRXZkd2JrYm9m?= =?utf-8?B?TXlVbU5EVjRVcFdVejVpWnhPeDVCYkhIMXQyWmdQc2VGUkVveDc0OGgxT2Q4?= =?utf-8?B?VUZZb0hSRStuNEFqNSs2NDN5Qk1UK2FNUkdiWUU0VkR0OWhXL3V1MlNpREpH?= =?utf-8?B?cmZ0UGJWbC9BMEsxNlZBU1J0R3orWHpocEVoY2p6cC9QZ05EbWwrNHVYYlJl?= =?utf-8?B?c21ta1ZEeUY1d0QrM0MxNVNVTHBvUXQ2cExpZmR2eVVKRjhBY3Y1MGhCUTNI?= =?utf-8?B?c2prblRzTXBLZzhDQVcreVV5Z0RKSmU4N0VEekpNTDkyRTFjQmJyQTM3OGsw?= =?utf-8?B?RVRWT3d1Qmg2cUlEbnZoU0xmQTY4Zk1OR0pvSVF5Slluc1hoVHRDQkxiVkZH?= =?utf-8?B?WStHTTBBMktqQXJaaCt3VG5qcVNZbHF5R2R1ODJJOEt2SFBIUGtPWnZiRnkx?= =?utf-8?B?NG9vMXduVkhCQkpLTEY3ekhmYjFQSk9rbTJpRXpaSDFCdnRYOVQyWkNzaEJW?= =?utf-8?B?L1BTSmJqc1ZxWERLTWQwN2hsb3kwckhrdWk2SHM5Q1h5UU5vT3JnQ1lzVkZQ?= =?utf-8?B?ZGxFY0hONi8zcjgvMnNQYk5nZXlzaktOaVZhN1RqYjg4L0Radnh4L1lUdVNS?= =?utf-8?B?WnhEVUdOc3NZeHB6VTVuSXZWRElGSDRqR2VQUTgwZ2dleXRiQm1ZM2JTeUtk?= =?utf-8?B?MW1wMjFNY1pzdjk2cXYwSVE2SVRHYVpvMEI1Y3NIZEpRQmwyelU0TDBFK1ZE?= =?utf-8?B?UzRSTGd6T2tnWXZVYzBJTFBqNDBiZm1POGNPSkxqM0FFOThZTVVpdTc5YmRv?= =?utf-8?B?THdZa0lYL1RabzVMWmovNHppc2xMM2lMNmlHTEExNkhRTXVXTzkrdkxEYmw5?= =?utf-8?B?aDZKN2lKMm1OVGp0dWhlWUxIblhPOTJLYnpUOFJkeEdKNEdmcHVGRGZ0OFpn?= =?utf-8?B?WmtBNVhOUFV0SzVyOHk0RkRiKzdqRUxSUVJ3L3JKaDhXak83OHFycUl2WEwv?= =?utf-8?B?SHJzd3VyUEFiYUJoUWJOLzgvLyt4T2xsR0liWnozWTBEeTZueXJtb0tRZDRZ?= =?utf-8?B?UW5FWmRSMXZ4Tis1ekNmYVM4L3lCZVZoV1hDUkg4ODQyYmZtZi9oeHMxVFl2?= =?utf-8?B?UXlualY2TmhxS1FJbHg2NnFBREIvbUJZVWNFVWVnTkpZdXNXN2JOMG14UnNU?= =?utf-8?B?Q2k3STErK3g4UlQrbjluTHNQZlB2aTRzbmlSUm5PKzJ3Rmc5c1hUUnF4YjlQ?= =?utf-8?B?UEZLYVphWHZSVDJ2eFVINVpaMjdUb091WXd4bEhqRzd0VmliakVGTUR5Nkhj?= =?utf-8?B?aEJ5MzdXckNwanpaa2lNMHRrUTc2V1NiTVl4ZUN6T1orWFZUTStSVmlwSzVk?= =?utf-8?B?TlFtUUNkL0pTcU40Q1Z1V0hKK1IrakhiRXU5WGRTYk1YaEsrWWNsTEdXUUE5?= =?utf-8?B?YkFoakJLWmdrdnVnanViZGNVUi9iOUVPMEIwQ0pZbUgzNHlsVDlJT1NDRlhR?= =?utf-8?B?QVh1dlNZbkttOHRxWm9NK01sRmNuTjRzS1hTdmlvenJiSnFZeUgvSDUrUFVV?= =?utf-8?B?ajA5cVYrU0NyNnA4NGR4RzloZlp1RUl0dnNFWjJGaUdTb1Q4MlEycjBOTlJq?= =?utf-8?B?eHNOUXpIejlLRldHc2ZCQ1VybHJDbmoxOUlIdWhXOTdWMkc3d3ZleEJVL1Az?= =?utf-8?B?ckV1eDNubS9HWHgvemZSRjZQY0xQNmhtbG5pUGNmeGZGcjJFY01hWWI2aU1I?= =?utf-8?Q?Pj62e6MLJh/RxHb8HAVAji9ROq2VbIntYbNJGmw?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 32b91ad8-525c-44d1-bdf4-08d900cdc7d9 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2021 11:50:07.2191 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Aou9bSI0lG6bX2LD0KRyx/lkbp0HcBJhC9zkq3349rQoHaprdSJXtg0ZAAEBsYJ2GbeS0FBUwVda1s5u1L+H0fr6SGsME9HsQXOKI/dBIBQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0065 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 11:50:15 -0000 On Thu, Feb 11, 2021 at 12:04:36AM +0000, Kent Watsen wrote: > Thank you for your review, Juergen! > > Below are responses to your comments. > > PS: this response took longer because I had to triage with Security Experts on a couple points. > It always takes longer. ;-) I cut things resolved. > - Does it make sense to have a new notation like > > > > | The diagram above uses syntax that is similar to but not > > | defined in [RFC8340]. > > > > or shall this simply become regular text? > > I find using tree-diagram like notation for features, identities, and typedefs helpful, especially in showing the “if-feature” constraints and hierarchical relationships between items. I recommend adding these enhancements to RFC 8340. It would be helpful if someone could whip up an I-D so these documents could reference the I-D instead of having the "The diagram above uses syntax that is similar to but not defined in [RFC8340]” language. > > That said, I also used a "rfc8340-like" diagram to list all the groupings in a module. It seems like the consistent thing to do, but I can’t imagine the RFC 8340 being updated to support that output, so I replaced that diagram, with a normal "xml2rfc" list, in the entire suite of drafts. I am sorry, I should have been clearer. My comment did not concern the diagrams but the mere fact that you have | The diagram above uses syntax that is similar to but not | defined in [RFC8340]. instead of simply The diagram above uses syntax that is similar to but not defined in [RFC8340]. and this is really an editorial nit if at all. The diagram itself I like, it would be nice to have them in RFC 8340bis. > > What is 'encoded in the format specified by the "format" identity' I > > assume this refers to the key value that is encrypted and stored in > > encrypted-value, no? > > Not only was the solution unclear, but it was rather upside-down in terms of how to encode encrypted values. Please see the “diffs” to get a sense for how the solution was changed. I happily trust Russ here. ;-) > > - I wonder why this is a SHOULD and not a MUST: > > > > "Identifies the symmetric key's format. Implementations > > SHOULD ensure that the incoming symmetric key value is > > encoded in the specified format."; > > > > This statement shows up several times when the key-format identities > > are used. I wonder what this means to an implementer. If I receive a > > key format (say one-symmetric-key-format) and a corresponding blob > > of data, do I have to decode this to see whether the format works > > out? If later the key-format is changed to something else (lets say > > octet-string-key-format), do I reject such a change or is it OK as > > long as the binary data I have would be a valid value given the new > > format? Perhaps this is implementation specific? Well, since we deal > > with keys, ... > > It currently a "SHOULD” because some implementations may assume that clients always configure perfect values, and so it becomes squishy as to if they MUST. If a server fails to validate the base64 contents (which are outside YANG validation) as they’re being applied, then the server may run into nasty exceptions when needing to use the value at runtime. A nice system will decode the base64 values and verify that they contain valid values during the commit process. > > Make sense? - leave as SHOULD okay? Thanks for the explanation. I am not religious about SHOULD vs MUST here. I have browsed through the diffs and they look good. I did not do another full review again. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 16 05:15:36 2021 Return-Path: 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 63E013A236E; Fri, 16 Apr 2021 05:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 GRFoLAyC4uSm; Fri, 16 Apr 2021 05:15:30 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40071.outbound.protection.outlook.com [40.107.4.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C0D3A2371; Fri, 16 Apr 2021 05:15:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jnoJAIvGVekHQl/qRiGD+IybBESB8Hjau4hquaLERMuYKyHXuFosy3KaxVOFXWAi+3eJyn7khGg3jRbzXADSHp1QDSmdCVhydD3gNLZYXkIFzmSN+q8B4TfaVOzpTbXmm7yp28GyT4fm29cmlXLJVIagJwb6fB/9Lc1zugkcnYaa8KZYXhuZdV+Z/c8mMLYhGzAKz2mqJC1t5umpXXs4wEM7+uojtfvBJ34+R2nwvMGDVf4HyQE9utd6rlOF55ZsNOWsIOe4wXo8FqpEHYEXb8oyjpB9EcfsuC1p2lGbKjGs9OB0Vh92xNmtHOriazqY7UcJaXlOfIjUlG+TnxAZGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dRYpr+7BRDsIri9FvuVduVkNGOuvqbdH6ZweZV28/Ws=; b=ceou7cGfVJt2JKjfYkhLPctDJY3w52h3UmmUFSNaSwQoJK1Gpe0jzn07Ek44YdUXrM/N2oT9tWXrkLX1VKQRAmucAZT/zuRxh+VYv7GWXqQWnu8UbiQ2lkAygICtf3IYNodkLy8k/EZkzHIACd9H1UiolSTDfE2v92qbydMKxPZSAewRNzKlT0fxUIh0aPW+bljQifkbOGIaTJINzzIGM0zwUozbd2kuBIJp6PAWh2C1PTPADgOExXS11H3Dbr0aHPW+Axnc684r4GTCiL0sMx590Oo6lz1JVR7cdAQqeMbo9s8y0Ym0ApO1LRFcEc8q0K8C9bJ0s0mYk5c9j86idw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dRYpr+7BRDsIri9FvuVduVkNGOuvqbdH6ZweZV28/Ws=; b=l87srOs3wptaWAb07EPJHGkVu0gIgY0AK/edSz5wJACCV37ml9L7W2ko6tONK2EWDX1xhb3zPvqu2szKSA7csihcF4X1tx+DfOAuOjPS/0+IR8ouocX9Af2lbMirQVGjaMOtqQsC/9zbN0Trbqso8dOFt4zxBA0bpNy5lb5T2sY= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1108.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:266::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Fri, 16 Apr 2021 12:15:28 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.019; Fri, 16 Apr 2021 12:15:28 +0000 Date: Fri, 16 Apr 2021 14:15:27 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: YANG Doctors , "netconf@ietf.org" Message-ID: <20210416121527.z7z42ptkhxc734vy@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , YANG Doctors , "netconf@ietf.org" References: <161047687248.13931.17900123352005904827@ietfa.amsl.com> <010001778e67c4e0-c179290b-6eba-46df-b17f-ec474c44783c-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <010001778e67c4e0-c179290b-6eba-46df-b17f-ec474c44783c-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM8PR07CA0027.eurprd07.prod.outlook.com (2603:10a6:20b:21b::35) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM8PR07CA0027.eurprd07.prod.outlook.com (2603:10a6:20b:21b::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.8 via Frontend Transport; Fri, 16 Apr 2021 12:15:27 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f764a260-67c0-4f23-22d8-08d900d1524d X-MS-TrafficTypeDiagnostic: AM9P190MB1108: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jPpKqGjnUy9s9SlYTRlcA0/zfsEPFlk6yDKmS670UTGPuB5QVo6gJhAatTHkBz5sQ/6jdCuJM76q1qyglitL9F3R1t5J1zU5/SZldA55X5BwWzhyro1MXOBDVFQi6sfZhFM2DpPNk3UqxcD+j5onBAuhYgm52TKnIylboWREX+ptv3pORVp0oG+997VDS/ir1rXAT4d7Ziv/Y1jzrViWy4WNSBWVnecg6/oMzl1lPunmkKAKFnLyguEBPV5X97aAmR717eCi3fMziWnCn2EC0GbWDA/BteyL2n/VhMgsxidy0vGzRse7zUPr9SfUAN/15fvmjq1tWvMW3yu2rQ6mih6CYpvwZuGY7+mq0q9j7aG/RmXvgxblQxhz8YFar4qsyQ7ffV4wupjiPe0sRHREacfw46BIF+/7h0ba1D/N7JZtUV1PCUGRjYFT9G15ku8GKjQKq4jFO9Of5zw3ze1O7Hy/ICEJh7ZG66XY2gAXAB7Is7p1IWonWZUBw5vuciEfN5cShWqNqz1zDdQQxW1dcHs7uvYVxYd0czkRD8yHxcsfBUgHgV99roaS55ReEsTAN7bvQGwbClBBDPiiwmw6MhveflT6JkjaXsSiizkKvp8tff0SEuUFBwCt6YpEMmxqoki0/SgnmWu0XvnfpqfgkRumJAKcnHP7IFebkcanDG3JRhwy1gVXTo7O7VNF9fbawIPjgTHEFSAfyIBwwKo21JbvSLzqk7bWL7tFvpGz14dnQ4bIpAHtpP28qt/g649u X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(366004)(136003)(39850400004)(396003)(346002)(38350700002)(2906002)(956004)(4326008)(26005)(38100700002)(786003)(478600001)(66574015)(1076003)(8676002)(83380400001)(16526019)(66556008)(316002)(86362001)(8936002)(66476007)(3450700001)(54906003)(53546011)(186003)(52116002)(6496006)(6486002)(5660300002)(66946007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?TGo4ZHFhNDR0ZGppZTZTckVIaktUR2doQnd2SlcvMW1jNE1DNXAwVTRRazV5?= =?utf-8?B?M3VEdVQ1WnYyU25LMTdNK3B1a0tXYVRBY2FZSTFZSW5wWU9QZU9ZV3F4QXBv?= =?utf-8?B?Z0hMZmxXeTluT2FrUThHM2dnb3kyTUNyWkNDYjNndk9GdlI0MEdIeTUzOHMv?= =?utf-8?B?VGJveEg3SUhpdUIreVN5c3RLenNoRlpDdXlmUzlaNXhwd0JIOEZPMmcwZ3A3?= =?utf-8?B?dTNYVEc3b0FKRzZDY3dWdkIzeTU5d29Gb3hieGxTRW5EdldCdFQ0RFNhaHFr?= =?utf-8?B?Zm9pOG9iZEZjRElLSi9ZeGVzRjZ1cmZzeUNyckNobmMySEtRL0xBSS96QXAr?= =?utf-8?B?Z2ZudldVYW81VWNtdjNoeE5zc1ZtYTVEeDNjcEdnYzRZT1pVQXV6d2t4Zld0?= =?utf-8?B?bEMyTGVZNlE4dVhoakZldUZKTzY0NUw4R2JpU2JXaWRpU0pDUzZqejFrUkN4?= =?utf-8?B?WCswM2d5VlhTUFVDOEo1SWhRRGxpa2NxbGthVG5PQWFwdndoa0MzelpmdDRW?= =?utf-8?B?ZVpmTzZJcjVxbVlvVVBIakNVMmFQL0RlaXRVaEFjTzZUdk5EQlptekx1a3Za?= =?utf-8?B?R0dVL2RZMzd1TXpXVHJLN1dYMXVQUG5OdnhLdU1pRzEzR0dsbXNqZWNhblIr?= =?utf-8?B?NUVnUzFqd2pZN2oxdXhMOHRjVU9xRHFDZTRReU92SlpOc2YxZ2J0ZWQrUUJR?= =?utf-8?B?UHdEeFV1MllyV0hJQ0MzT25tNXlGY0ZJRG1DZHRxOVdzMkl3Zm9jU0x2aVpO?= =?utf-8?B?cXhMVUt0UjdXWExlL0s1UmhsL1VCTEZ0c0ZWVWZ3OHExMGNWeHkraTFuTmVu?= =?utf-8?B?NlcvRzN6ei9pTFlhOTcvd3BLZTZ1eGcxSG5UdlZUTWZmSy9sOEt1cnBWVnZ2?= =?utf-8?B?YllPUGVyd1JPcjZMZGU1M2xMd01tcXdXUnFjNHh3RWRCVUk4Y0s5dkY1VHRt?= =?utf-8?B?VExpQ1B5NkFadUZ2b0JBOVM0NjF3bUZPb2xtNTN2bGFlUGZuV1lUZ2dmTEdm?= =?utf-8?B?dEtCMzZnNFljRXVvZTRVTXZVRGk3RzJVMWJTSFo2MGhTQmNKbGZwQ0lXd1By?= =?utf-8?B?U1Mzd2JHMG1YQXp6eWYyOXd5YmhIM2Z5cmJQelBWUjVDVG5YblREUXVnRE1K?= =?utf-8?B?b1dOS25ONFQ5enFDZUl1RzZKRDh6MjB4c1NNSGU3NW96OGtFaHZNUXhsd1V2?= =?utf-8?B?TEJzLy9zZFR3VmIwemNmVEJRTDUwazhvdDJ1bzU1TUd2VSszMW9oSE8yNmhz?= =?utf-8?B?Y2Zlb3d3SjBaeDh1SzkySEdwOXdmRjhSZHI5eE5IcGw1VjJya3R2Y0VtaHUz?= =?utf-8?B?MG5rYittWWZZQVpNdmVVaWlvQ2E3K0t2QXd6NER5MzdOTVZDOHpmSG9jWm9y?= =?utf-8?B?c3dyM0daalhGRzU3Z2lkOU1QSVYwdTlzamJ2aVJMdVpWQUtnU2RBSWVRRWxs?= =?utf-8?B?a2pPSW5TaS91WExxUVJ1U21VQlk5OEQ3MGk2RzFiU2Y2WnU2bm1rYzhjeHVw?= =?utf-8?B?V3NURFU1cEFoQy92bnFUaWxQRjRLRkw1d2ZZSlVoVGRTWDltRHlDMlJ4NDRv?= =?utf-8?B?QlBMVFlLKzBjUWNwa1N6WVArbmN0OUp6SFh3U3hPV0FhVGwzRDViMVZFT3NX?= =?utf-8?B?eVkrYnhlWkhwaVhuL2hZOG1yczFId3Z2NEQxK3NDcFN0dE5XQ2lqQnRpRDd2?= =?utf-8?B?VU91UnNMdGxxZjZuSnFtelZ1cGY2bnh3VU5Ma08rNTNoS3VIYk9PYytIOWhH?= =?utf-8?Q?WAtGGkTQPYgyr18+1A04EX3INRayjPHI3lxbIXk?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: f764a260-67c0-4f23-22d8-08d900d1524d X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2021 12:15:27.9633 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WvNnSBZ4wS3piLwOZqkKXI87WyxaPkxFDclfJ04bMX/6w4csbn+U+mIUlzhvrqV48whuZdGlh4O15BhhGnyM2CsHorMnazWiDYaJ8YCtF78= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1108 Archived-At: Subject: Re: [netconf] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 12:15:35 -0000 See inline, I cut what I feel has been resolved or does not deserve a further comment. On Thu, Feb 11, 2021 at 12:05:01AM +0000, Kent Watsen wrote: > > > On Jan 12, 2021, at 1:41 PM, Jürgen Schönwälder via Datatracker wrote: > > > > Reviewer: Jürgen Schönwälder > > Review result: Ready with Issues > > > > The crypto modules aim at providing a flexible reusable infrastructure > > of groupings for modeling cryptographic keys and related concepts. The > > flexibility of the definitions provided of course comes with a certain > > amount of complexity. > > > >> From a YANG perspective, draft-ietf-netconf-trust-anchors-13.txt is in > > a good and close to publish state (a couple of minor issues left). I > > also tried to understand what is being modeled here and hence I also > > have some questions concerning the concepts modeled and I hope these > > are easy to answer/resolve as well. > > > > - I have compiled the YANG modules using yanglint 0.16.105. > > > > - The prefix 'ts' is rather short, the set of two letter prefixes is > > rather small limited. This comment also applies to the other > > documents, crypto-types uses 'ct. Perhaps this is not a problem > > since collisions can be handled but if we go for rather short > > prefixes, we will have to exercise the collision resolution. (I see > > that 'ct' has already been used by ietf-complex-types, RFC 6095.) A > > possible alternative could be to use sec-ct, sec-ts, sec-ks, ...). > > Ugh (me, whenever a naming-discussion comes up ;) > > I don’t know why prefixes are registered, as the prefix is defined at the top of each module. The only value I see is not syntactic but rather for consistency, to aid human readability across disconnected sets of modules. > > Prefixing the prefix with “sec-“ may work for trio of drafts you just reviewed, but it seems undesirable when getting to the client-server drafts, as they're more *protocol* oriented. If “ks” and “ts” aren’t taken, then maybe we claim “first mover” advantage? If not, then maybe “kstore” and “tstore” might be meaningful fallbacks? Assuming we claim “first mover” advantage for “ks” and “ts”, then we just need to handle “ct”, which maybe could be “ctypes” or “cryptypes” or “ct2”? So, 1) prefix the trio or 2) claim first-mover advantage on two and figure out something for “ct”? …or maybe 3) keep “ct” also noting that a) “SHOULD NOT” is not a “MUST NOT” (in the text below), b) my “rant” might have some merit, and c) short and terse is nice (per your next comment). > I suggest you think over it and pick whatever you think seems to be a good solution. ;-) > > - Is the feature truststore-supported really needed? Does the YANG > > library not already provide the information whether a module has > > been implemented or just imported to access type and grouping > > definitions? > > This was discussed before. The bottom of Section 2.1.4 says: "The reason for why the "truststore-grouping" exists separate from the protocol-accessible nodes definition is to enable instances of the truststore to be instantiated in other locations, as may be needed or desired by some modules.”. Case in point, the MacOS “Keychain Access” utility maintains both system-level and user-level trust anchors. [UPDATE: you had a similar comment in the keystore draft, which you self-resolved there and then said to ignore this comment. Just the same, let’s ensure the drafts are clear.] This explanation gives a reason why there are groupings. My question concerned the feature truststore-supported. Is the YANG library not already providing the information whether a module has been implemented or only used for getting access to definitions? In RFC 8525, you have a list of modules implemented and a list of modules used for import only. My question is does feature truststore-supported mean the same as the module shows up in the implemented module set in the YANG library? > > - Does it make sense to be explicit about the fact that the cert/key > > references are all weak references in the sense that they can exist > > without the corresponding cert/key being present? In other words, in > > order to safely delete a cert/key, one would have to check that > > there are no dangling references left (which is difficult in case > > references are scattered over multiple (proprietary) data models). > > For YANG savvy people this may be obvious since there is no > > require-instance statement in the leafref type definition but not > > every implementer may recall this - and it would be good to document > > that using weak references was an explicit design decision and not > > an oversight. > > Correct, there are no "require-instance” statements, but the "require-instance” statement defaults to “true”. Do you mean the text should be explicit that strong references are enforced? Oops, my understanding of YANG is aging. Since referential integrity is required to be valid, nothing needs to be said I think. Ignore my comment. I have looked through the diffs, looked all good to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 16 05:38:06 2021 Return-Path: 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 7CD1B3A240B; Fri, 16 Apr 2021 05:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 dLB1nRHsz4Zn; Fri, 16 Apr 2021 05:37:57 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60082.outbound.protection.outlook.com [40.107.6.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8B93A2433; Fri, 16 Apr 2021 05:37:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kgtIPDm8UdT6y9XYDthJ9y0q5uc/ecFUgAWOh3xm+QO9C4JnLdBc7RH8HF/G6mBAvmJzzr4YEN9POAriEvXMg2ZPKHDrdPZJpZaXo/O9yTMx0/CtSpK/DYUL1PnXy7B5uSiS7yoig0o8996kZZ6k2sbvyGqTi/mdvxtgL/jWvNenYnL9qWHkwRNrf69rKN6G8OoLL7PK7Xi4VHP7XIqFet9Gna/+76llWoBBtEyLWJwqRwA87tCt+ZJBjHPs7m7Z7WbPcNK5cfRfOjVEVUSnwlsD+9VeTEZup5vGViTntzcTy616hKVNDsTpIArqwu8OLt/c7+Cu+BhgmEk3RHngag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fB9Qjq0P5LY36o7TasL+07/JZfcZ9ZgvDD1mCJ/94+M=; b=cScu+Kw0Ed5rWNmdJbqbY8OLsQzTuID3J5m84cRnoYPn8KozxUPrmSROBMs4co5k8ngKt7UnRRbQDX9vSpko1seXAVuI7kx6yTYVwngi9Q6fMHwQorIYgTOCB+BrvUkVHCmUANFJpGWFC6JtZr9LfXi8LYsl2mGT7ROAo7NrogPqQ3r5blRO+z2VWtBe8SpkYlHGBRXdku2/lVCgpJdJ7mSQYIV0kZz84rLg+XKNhVWvMp7bxGtHFQaKDHNFV7n1+mJWOZQK6H6t8LX54AVnjWxiUNswqENdHtcl5QFledYfmSH7HalKONABmZLsiMFwp1wR/O3glT9mcni0yEKCAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fB9Qjq0P5LY36o7TasL+07/JZfcZ9ZgvDD1mCJ/94+M=; b=f6j6hhBo5bBF4qJCUi9q/XqCODKeNWqjnBWvYjeHMH/jx9NFcdRs2n0xc5SBYgH16Y2suplHIVBYt281vfeEvcmntKdXWi+U7azFISej+K0f39TMqsnqE3sKtqyeYka68GmdWk0GgqyfWNRzn5WJdqxtkyiVt4s3zq3yoOF0Hxs= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1297.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:262::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Fri, 16 Apr 2021 12:37:53 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.019; Fri, 16 Apr 2021 12:37:53 +0000 Date: Fri, 16 Apr 2021 14:37:49 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: YANG Doctors , "netconf@ietf.org" Message-ID: <20210416123749.246d6irnd3oso3x4@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , YANG Doctors , "netconf@ietf.org" References: <161064362767.26403.10249622617283363882@ietfa.amsl.com> <010001778e68398d-c2bff7b8-4c4e-4f30-a962-1ce39e2ece13-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <010001778e68398d-c2bff7b8-4c4e-4f30-a962-1ce39e2ece13-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR1P264CA0034.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:19f::21) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR1P264CA0034.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:19f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Fri, 16 Apr 2021 12:37:53 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8f5928ee-fe64-482c-a854-08d900d47445 X-MS-TrafficTypeDiagnostic: AM9P190MB1297: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Xapxya3d/JElI6D+vMXAnq1R26Lzcum1s2IktL5DLxt0TCTTDab2BbADZUWdNYAVgvHrhz1eWcKwJWIuZgPCQoz+eGqk26Akx3I90OGGCMPLXh8kr+ID3Lv6SdX/eE7HdocLLvVOhdviZBYdluefQu3CkjULZvXCw+Xt41Jzodr7fQdGktcmgSxhBgw6Q0mIMHvqS6VOSEZGTDMGsP8vge8GDqY8Ti591Ht5yOgPn1h+vczNHHvDu9yg+UQjOke3r3RIN7NcnffhFsyO1Kv7zNc24ScTdCx9WahdcBj0IU4AlTDjS5DyYsVADc8LiookIlbo9qXP+e9wfj70K05bmaf1xg+28dU4bZrNGEgROi6xxKOrIRUPEmkscdJDQ0h0DsAb3e/pogZl8oRuLK+MfH8q6bBX4B1GZUCP+/RqzUgyJf4sEnOZhhgz8rC3RTcYePHF+s3WVYP8t7w9FBn02PXhARbGQGSWGBklc0R/qEgGKpTBE+HrJDw/HU9+a92b26zZ1caLtJr+1QfDEPbMbV5Arz5vmR8LGSPg/XGJzp4Gu4wAcWib/sfICBD0AtDh1tjzEBFfp0bLTZEWQTtD4r8lLgqun+YPHdpg8mr/kUyZhFHKhkqNiPb98oYTcV88j3sx7ABtrnaSrf1qKXkSnC4gtWviOBagPr066fYBtHc2VAZ5+OmmBVsk20ds/z/fgcz25ca2YXAvr75ug8NyYc35zrxVRM1ElL6wxiG3V8w= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(346002)(136003)(376002)(39850400004)(396003)(8676002)(478600001)(4326008)(8936002)(38350700002)(52116002)(16526019)(38100700002)(6666004)(5660300002)(316002)(786003)(66556008)(2906002)(86362001)(6486002)(54906003)(66946007)(3450700001)(1076003)(956004)(26005)(66476007)(83380400001)(186003)(6496006); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?TDdaalFia3BQZmV4ZlpHV1BWWi9VTStKS1BXYkFkdWh4M0d6MmY3c0xsZFhX?= =?utf-8?B?MXlQWnN5ZldFUVV0bktzbXR5UXZJQjNFWmdqanpIeEgvK3hCemNjVVR4aWxP?= =?utf-8?B?MVBVdHA5M1U2UFNaQ0lPbFVZZzNIZTVrY3p4WmtZaVNFdzllSGtYSEwxcjFY?= =?utf-8?B?UkI0RExHV1p3VnNQSmNPaXhOcUFJemhhYTN0N1VVcEhMOGxVUEVWTVppbFdu?= =?utf-8?B?dXNkUUdFYll6Q1ozbGpCeXJkVWZZTW5sbkwyVXM3WVgzWk4vSlVYSTNaTzlU?= =?utf-8?B?eGxFL2ovK3o5VE95K1NScHZkekpjSW0wTGx3cGRhcDYwVFd0L0cyZ1BPRFE2?= =?utf-8?B?djBZNm5hQmExZ0VCRXg2Vk42aVllaXlKVVpsdEhRaFQ1K0I5dGdiK2lPeitM?= =?utf-8?B?WXVUTEhSYTgxZm1XZzNKL3F4WXNDUlNrcS9BaTRGa2tVWXFqMDFpTkJxMVE5?= =?utf-8?B?L25abXQ3bGw1ZVd1Uk1JMUpWNUxLaFY5T1lmb2tGUnpZT21yL0hiT1N6ekNn?= =?utf-8?B?SW0yMHdPQS9JNVBjSjdiL2E5VzU1VG1WcTV3ZisybVI5RkNka0xEOTc4eVlU?= =?utf-8?B?TUF6OVRXc09wcEdXMnNtYVJhRkl2SmUwZTU2Y2VDZVVXa1IxQW1LekZDa2Mr?= =?utf-8?B?eDdIdGExYU12bnR6d3FvZm81MXpHbEd3ZW9pYmo2SDVRbU0xVnZiUTliNE9a?= =?utf-8?B?clQyT3QweFg0UDd5SjNmYzlkR2lEVW4vY1VzbmR2V3RTaXlxNjhRQU92M2lm?= =?utf-8?B?L0praDJtcjROcDZLMHc0c1FXOXhRTlQ5THJwNS9hWGRnSHFFUzdBdXNmWEdM?= =?utf-8?B?aVl2TnEyVFBhR2FvNFh3aEM2clRNU3RjSmpZVmJtNkhCYWdKUlVmR3lPbFJP?= =?utf-8?B?R21haHo5ejF5REE4eFUwNVh4cEtNNDl3T1hHKzlBa3hVaUtKWVp6SHhwTm93?= =?utf-8?B?MmpCSDFydm44bjZMR2FLWlZLYUdlZENRSDFrTEF6SDIxRjVxRkpIN1QyV012?= =?utf-8?B?WFBadFl1QUp4WThTOTc3RW5HSmNmS00rRmRIbEkrNXk1Ymg5OFZLdG5rb0lQ?= =?utf-8?B?TDNwQmtQZTRRdGo3NkZMQ0djUzlqWS96dVI1U3MwMlJxSWVLQkxYR3NEekZn?= =?utf-8?B?ZTBwa1J5SGl0WVhXeFdLQU94eDc4b1piVWluOWl2THB1TTAxSUlXQ2wxUkZ5?= =?utf-8?B?d0FCb3FOZzQ3RDcvR1FpNHhxV1FXQ3N4UmV5QzBMWnNQNThKanliSVNJMmFi?= =?utf-8?B?cXp5dTZaTytBTE0vVWlzdW1NNG9wckQ4OXVRaHVwdHR3TzVST2lUbVdueExV?= =?utf-8?B?dGVMUFdXWnBqWFkvWUxIOExab1VtZlllbWdZUEhJVWZEZ3o1emRwYkFFQlBi?= =?utf-8?B?T21BRDIzMDdhS3oreDRWTWNOTnYyMDJ6eFNkc2NvMFNtMG1DcmdEbXFlSG5s?= =?utf-8?B?SjBPRGFhdkFNWEJnYk9aZ3I1LzZXMUI1bS9TUk9ZREpXUjRwTnV1UU05MmYx?= =?utf-8?B?TGdiMVZKbjJOZHFQVll6OXlsUWhXeWtYVDZVbldLakc2UURxUmI4a2pEMi9X?= =?utf-8?B?QTlBSVFXNCtrQzNDbi94dzFiVmFnWnRFbXF4N05BdG5XWjZTMjhVSHdtdlFB?= =?utf-8?B?czJ6NmFaS0ZmNjU5NXdFUXJtZjhsZjByQWI5S2tzZDVEWUw2N1NyYWQwQXFi?= =?utf-8?B?dFE4eStra2NjblBNbTR3TUUwZnU4TklVcmJBMEhBRkJtdXJVTEJ4V0RPWCtx?= =?utf-8?Q?CgrTN/yk2jhnPZMdT3U5wwJeCcytt3dvovcwKqO?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 8f5928ee-fe64-482c-a854-08d900d47445 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2021 12:37:53.4549 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: vKrE+xyLg9vU3VvhQUYyjTgQs8z7qImVJKl/ZN4QiqM3x6PkkKBE/1Zm7UHAe0gXCodz5kTc9e7G6hDlNQGzeRIxPskFTS4kaX3Mf13X7iI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1297 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-keystore-20 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 12:38:02 -0000 Trimming to the essential parts... On Thu, Feb 11, 2021 at 12:05:31AM +0000, Kent Watsen wrote: > > - Is the feature keystore-supported really needed? Does the YANG > > library not already provide the information whether a module has > > been implemented or just imported to access type and grouping > > definitions? OK, I know see that this is used to make definitions > > conditional, hence it makes sense. This means that my comment on > > truststore-supported in the other review can be ignored, I found > > the answer. > > Please see my response to your comment in that draft’s review. The net-net appears to us just needing to ensure things are clear enough. > See also my comment on the other document. My question was whether this bit can already be picked up from the YANG library. > BTW, “keystore-supported” may not be the best name. “keystore-implemented” is closer, but maybe “keystore-module-implemented” or “central-keystore-implemented would be better still? One question is if the “central” (or “global” or default?) prefix should be a term used throughout the draft. The latest update has text like “… the keystore, when this module is implemented”, but this might be better if, e.g., “… the central keystore, when this module is implemented”. Thoughts? I think this is better. > > YANG's reference mechanism via leafrefs is not really supporting > > well what you try to do. I understand the flexibility you want to > > achieve but it seems YANG 1.1 does not really support this well > > enough. What you would need is a leafref type that can be "anchored" > > at different places but we don't really have this... > > I don’t understand this comment. But looking to my previous comment, a way has been devised that works. It may be kludgy relative to what you have in mind, but it seems to work. > Yes, kludgy is perhaps a good term. And you are hitting YANG's limitations, there is not much you can do different. > > - Section 4 points to keys being compromised 'when in transit' but I > > think we also want to protect keys at rest, i.e., sitting in a > > backup. > > Actually, Section 4 is all about protecting keys at rest. What text are you looking at? I do not recall, lets ignore this comment. > > - Section 4.3 talks about _highly_ restricted access mechanisms and > > _highly_ authorized clients and I am usually a bit confused what > > _highly_ means. But I am YANG doctor, not a security reviewer. ;-) > > Trying to say that, e.g., the NACM should only allow a "crypto officer" access to the MK’s cleartext value. So is NACM the 'highly restricted access mechanisms'? Should it be OLD highly restricted access mechanisms SHOULD NEW access control mechanisms like NACM SHOULD OLD highly authorized clients NEW authorized clients My point is that "highly" simply does not mean anything (to me). I browsed the diff, the changes look good to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 16 06:42:19 2021 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3509C3A2657; Fri, 16 Apr 2021 06:42:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161858053415.948.17142725776470149430@ietfa.amsl.com> Date: Fri, 16 Apr 2021 06:42:14 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-16.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 13:42:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Modules describing Capabilities for Systems and Datastore Update Notifications Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-16.txt Pages : 27 Date : 2021-04-16 Abstract: This document defines two YANG modules,"ietf-system-capabilities" and "ietf-notification-capabilities". The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG related system capabilities for servers. The module can be used to report capability information from the server at run-time or implementation- time, per the YANG Instance Data File Format. The module "ietf-notification-capabilities" augments "ietf-system- capabilities" to specify capabilities related to Subscription to YANG Notifications for Datastore Updates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-16 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 16 06:42:53 2021 Return-Path: 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 B80A33A26B2 for ; Fri, 16 Apr 2021 06:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 grkj3cgKgB5D for ; Fri, 16 Apr 2021 06:42:42 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EDBF3A26C8 for ; Fri, 16 Apr 2021 06:42:36 -0700 (PDT) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FMHLw3t5jz68BlW for ; Fri, 16 Apr 2021 21:37:12 +0800 (CST) Received: from fraeml740-chm.china.huawei.com (10.206.15.221) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 16 Apr 2021 15:42:32 +0200 Received: from DGGEMS404-HUB.china.huawei.com (10.3.19.204) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Fri, 16 Apr 2021 15:42:32 +0200 Received: from [10.47.79.27] (10.47.79.27) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.498.0; Fri, 16 Apr 2021 21:42:26 +0800 To: Kent Watsen , Benoit CC: "netconf@ietf.org" References: <172a3cd6-dd95-c535-23d0-ffbd879d6319@claise.be> <01000178d3063b0c-963bb741-e8e6-41bc-821e-bb25b421ed26-000000@email.amazonses.com> From: Benoit Claise Message-ID: Date: Fri, 16 Apr 2021 15:42:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <01000178d3063b0c-963bb741-e8e6-41bc-821e-bb25b421ed26-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="------------2F20C9ED5E783F1F5CA43903" Content-Language: en-GB X-Originating-IP: [10.47.79.27] X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Shepherd review of draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 13:42:52 -0000 --------------2F20C9ED5E783F1F5CA43903 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Thanks for your review. See inline, after some clean up. I addressed your two remaining comments and I posted a draft version: draft-ietf-netconf-notification-capabilities-16 >> >> >>>>> >>>>> >>>>>> - is the comment "The special value '/' denotes all data nodes in the >>>>>> datastore.b consistent with XPath 1.0 expressions. >>>>>> BALAZS: we are consistent witjh the NACM RFC, which says: >>>>>> B B B B B B B B B B B B B B B B B B B The special value '/' >>>>>> refers to all possible >>>>>> B B B B B B B B B B B B B B B B B B B datastore contents."; >>>>> >>>>> Then the comment should say b Section ???, the special valueb >>>> Done. >>>> B B B B B B B B B leaf node-selector { >>>> B B B B B B B B B B B type nacm:node-instance-identifier; >>>> B B B B B B B B B B B description >>>> B B B B B B B B B B B B B "Selects the data nodes for which >>>> capabilities are >>>> B B B B B B B B B B B B B B specified. The special value '/' >>>> denotes all data nodes >>>> B B B B B B B B B B B B B B in the datastore, as specified in path >>>> YANG object in >>>> B B B B B B B B B B B B B B data definition statement [RFC8341]; >>>> B B B B B B B B B B B reference >>>> B B B B B B B B B B B B B B B "RFC 8341: Network Configuration >>>> Access Control Model"; >>>> B B B B B B B B B } >> >> Looking at the new draft, I see the added clarification (thanks), but >> it’s a bit difficult to read.  Would this help? >> >> OLD: as specified in path YANG object in data definition statement >> [RFC8341] >> >> NEW: consistent with the “path” leaf node on page 41 in [RFC8341]. Done. Did not include the double quotes around path to avoid troubles. >> >> >>>>>> - this command detected a number of issues: pyang -f yang >>>>>> --keep-comments --yang-line-length 69 >>>>>> ietf-notification-capabilities\@2020-03-23.yang > tmp; diff >>>>>> ietf-notification-capabilities\@2020-03-23.yang tmp. (whitespace >>>>>> at end of lines) >>>>> >>>>> No response? >>>> That was an oversight. Done for both modules >> >> Thanks, but be mindful that tool’s opinion is not always perfect and >> that discretion can override it where preferred.  The primary intent >> is to show that an effort was made... >> >> In particular, the closing “; for the "import ietf-yang-library” >> statement is on a line by itself.  IDK if the tool is suggesting >> this, but I think it better if the closing “; were brought up to the >> previous line. Corrected. Regards, Benoit --------------2F20C9ED5E783F1F5CA43903 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Kent,

Thanks for your review.
See inline, after some clean up.
I addressed your two remaining comments and I posted a draft version: draft-ietf-netconf-notification-capabilities-16





- is the comment "The special value '/' denotes all data nodes in the
datastore.b consistent with XPath 1.0 expressions.
BALAZS: we are consistent witjh the NACM RFC, which says:
B B B B B B B B B B B B B B B B B B B The special value '/' refers to all possible
B B B B B B B B B B B B B B B B B B B datastore contents.";

Then the comment should say b Section ???, the special valueb
Done.
B B B B B B B B B leaf node-selector {
B B B B B B B B B B B type nacm:node-instance-identifier;
B B B B B B B B B B B description
B B B B B B B B B B B B B "Selects the data nodes for which capabilities are
B B B B B B B B B B B B B B specified. The special value '/' denotes all data nodes
B B B B B B B B B B B B B B in the datastore, as specified in path YANG object in 
B B B B B B B B B B B B B B data definition statement [RFC8341];
B B B B B B B B B B B reference
B B B B B B B B B B B B B B B "RFC 8341: Network Configuration Access Control Model";
B B B B B B B B B }

Looking at the new draft, I see the added clarification (thanks), but it’s a bit difficult to read.  Would this help?

OLD: as specified in path YANG object in data definition statement [RFC8341]

NEW: consistent with the “path” leaf node on page 41 in [RFC8341].
Done.
Did not include the double quotes around path to avoid troubles.


- this command detected a number of issues: pyang -f yang --keep-comments --yang-line-length 69 ietf-notification-capabilities\@2020-03-23.yang > tmp; diff ietf-notification-capabilities\@2020-03-23.yang tmp. (whitespace at end of lines)

No response?
That was an oversight. Done for both modules

Thanks, but be mindful that tool’s opinion is not always perfect and that discretion can override it where preferred.  The primary intent is to show that an effort was made...

In particular, the closing “; for the "import ietf-yang-library” statement is on a line by itself.  IDK if the tool is suggesting this, but I think it better if the closing “; were brought up to the previous line.
Corrected.

Regards, Benoit
--------------2F20C9ED5E783F1F5CA43903-- From nobody Mon Apr 19 10:48:08 2021 Return-Path: <01000178eb3f0c88-bfd76315-200a-4bcb-982f-8700be82ef77-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 2738C3A3C61 for ; Mon, 19 Apr 2021 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 DKf0-eGMvNng for ; Mon, 19 Apr 2021 10:48:02 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828743A3C5F for ; Mon, 19 Apr 2021 10:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618854481; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=MtKBs+GvnTdTGV2lWkQW6IwaGUHCqsRteXX8orh8mhc=; b=JHdeWVw30aVpPMKIiidJ2iP7dBl66uCp1G+CwZt0YPzHxaLbIIP3pQbVXvoMneln Mx+h61jEo5PaKU9ukq0cll1UFdIZIUqe/Nh1gnel7kcsTPAokUHwNeegs1BfpckJvui Pac3uZJ3CrYeK+7tecQScIty4bsCgLTp0aBbW6Cw= From: Kent Watsen Message-ID: <01000178eb3f0c88-bfd76315-200a-4bcb-982f-8700be82ef77-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BE7172E0-9998-4617-AB58-ECF3D7C24285" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 19 Apr 2021 17:48:01 +0000 In-Reply-To: <66c7-606b1980-11-21ab2140@196626001> Cc: "netconf@ietf.org" To: =?utf-8?Q?Michal_Va=C5=A1ko?= References: <66c7-606b1980-11-21ab2140@196626001> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.19-54.240.48.92 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 17:48:07 -0000 --Apple-Mail=_BE7172E0-9998-4617-AB58-ECF3D7C24285 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michal, Please find responses below. K. >>>>> - ietf-ssh-server, = ssh-server-grouping/client-authentication/supported-authentication-methods= >=20 >>>>> Since the "other" leaf-list was removed there is no way to support = some other methods than those specified. I am not sure whether this was = the intention and if so, what is the reason for it? If nothing else, we = support "interactive" authentication method but there are some others = that I see no reason why they could not be used. >>>>=20 >>>> It took me a bit to determine that this change happened in = ssh-client-server-18. >>>>=20 >>>> The motivation behind the change was to align the values with those = defined in RFCs 4252 and 4250. >>>>=20 >>>> You mention an =E2=80=9Cinteractive=E2=80=9D and =E2=80=9Csome = other=E2=80=9D methods - where are they defined? >>>=20 >>> That is a good question. It seems no other methods are standardized = but that does not mean they are not used. >>=20 >> What change are you hoping to see? Is there anyway that such changes = could be augmented in, or must they be in the base module? >=20 > Okay, so properly looking at all this, the 2 missing authentication = methods (that are supported by libssh or sshd, or example) are actually = standardized so I suppose you can add them directly into the YANG = module. There are "keyboard-interactive" [1] (not "interactive") and = "gssapi-with-mic" [2]. >=20 > [1] https://tools.ietf.org/html/rfc4256 = > [2] https://tools.ietf.org/html/rfc4462 = Thanks for tracking those RFCs down. =46rom RFC 4256, the "keyboard-interactive=E2=80=9D auth method was = added here: = https://github.com/netconf-wg/ssh-client-server/commit/6cc6a9ecd0be7db01c6= a1ba39ed7b32ac6310163. =46rom RFC 4462, the "gssapi-with-mic=E2=80=9D and =E2=80=9Cgssapi-keyex=E2= =80=9D auth methods were added here: = https://github.com/netconf-wg/ssh-client-server/commit/ea518a6d7accc1cda65= 6a5d1bc1300abf1c62f5a It would be great if you could verify these additions. I=E2=80=99m not = myself configuring any SSH clients or servers, and thus the = configuration-formulations are purely academic based on my reading of = the RFCs. Additionally, in ietf-ssh-server, the whole "client-authentication=E2=80=9D= container, especially its "supported-authentication-methods=E2=80=9D = and =E2=80=9Cusers=E2=80=9D descendent nodes, seem less than ideal. = Have you been using these trees, do them seem to be formulated = correctly? >>>>> For a robust and extendible solution, why not use an identityref = leaf-list with all the methods as identities? One could then simply add = new ones with specific "if-feature" statements. >>>>=20 >>>> An identityref seems reasonable, could you propose a snippet of = YANG for it? >>>>=20 >>>> That said, it seems equally possible for a future module to = augment-in a new leaf under the "supported-authentication-methods=E2=80=9D= container... >>>=20 >>> Right, that would solve the problem, too. So you can keep it the way = it is, up to you which solution you prefer. Not sure why I did not think = of augments first but identityrefs. But identityrefs are much more = general so the implementation should probably depend on whether these = authentication methods are to be used only for this single purpose or = not. >>=20 >> Either way is fine with me. As the module is in WGLC currently, it = would be good if others could express an option... Anyone? >>>>> - ietf-netconf-server, grouping = netconf-server-grouping/client-identity-mappings >>>>>=20 >>>>> The "if-feature" on this container is strange. The practical = problem is that if one wants to support certificates only for TLS, both = one of the TLS features and "ssh-x509-certs" must be enabled. This then = results in the container being defined for both SSH and TLS so there is = no way to support it only for TLS or SSH. >>>>=20 >>>> Yes, granular features would be nice. This issue is tracked here: = https://github.com/netmod-wg/yang-next/issues/82 = . A possible fix = would be to enable features on a per-XPath basis, perhaps using the = =E2=80=9Cnode-tags=E2=80=9D draft going on in NETMOD. Do you have a = proposal? >>>>=20 >>>> BTW, shouldn=E2=80=99t the =E2=80=9Cif-feature=E2=80=9D statement = have an =E2=80=9Cor=E2=80=9D (not an =E2=80=9Cand=E2=80=9D) between the = two major expressions? >>>=20 >>> Yes, I think "or" fits much better. I just was not sure whether = there is not a specific reason why "and" was chosen. >>=20 >> OLD: "(tls-listen or tls-call-home) and = (sshcmn:ssh-x509-certs)=E2=80=9D; >> NEW: "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"; >=20 > Well, this is no good either because now ANY of those features are = enabled, the certificates will be supported for BOTH TLS and SSH. What = should be possible to support is X509 certificates for SSH, TLS, or = both. That would require some more remodeling of = "netconf-server-grouping", not just an "if-feature" update. But I wasn=E2=80=99t trying to fix your original issue. As mentioned, = there is a YANG-next issue and the best that consuming modules can do is = to 1) enable all the features defined in these modules and 2) augment-in = =E2=80=9Cuse=E2=80=9D-specific feature statements where the groupings = are used. My OLD/NEW update is trying to correct a logic error. I believe the new = formulation is correct. It could be expanded to; (tls-listen or tls-call-home) or=20 ( (ssh-listen or ssh-call-home) and sshcmn:ssh-x509-certs) But I don=E2=80=99t think "(ssh-listen or ssh-call-home)=E2=80=9D is = needed, as certainly one would be true when "sshcmn:ssh-x509-certs=E2=80=9D= is enabled, right? K. --Apple-Mail=_BE7172E0-9998-4617-AB58-ECF3D7C24285 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Michal,

Please find = responses below.

K.


- ietf-ssh-server, = ssh-server-grouping/client-authentication/supported-authentication-methods= > 
Since the "other" leaf-list was removed there is no way to = support some other methods than those specified. I am not sure whether = this was the intention and if so, what is the reason for it? If nothing = else, we support "interactive" authentication method but there are some = others that I see no reason why they could not be used.

It took me a bit to determine = that this change happened in ssh-client-server-18.

The motivation behind the change was to align the values with = those defined in RFCs 4252 and 4250.

You = mention an =E2=80=9Cinteractive=E2=80=9D and =E2=80=9Csome other=E2=80=9D = methods - where are they defined?

That is a good question. It seems no other methods are = standardized but that does not mean they are not used.

What change are you hoping to = see?  Is there anyway that such changes could be augmented in, or = must they be in the base module?

Okay, so properly looking at all = this, the 2 missing authentication methods (that are supported by libssh = or sshd, or example) are actually standardized so I suppose you can add = them directly into the YANG module. There are "keyboard-interactive" [1] = (not "interactive") and "gssapi-with-mic" [2].

[1] https://tools.ietf.org/html/rfc4256
[2] https://tools.ietf.org/html/rfc4462

Thanks for = tracking those RFCs down.

=46rom RFC = 4256, the "keyboard-interactive=E2=80=9D auth method was added here: https://github.com/netconf-wg/ssh-client-server/commit/6cc6a9ec= d0be7db01c6a1ba39ed7b32ac6310163.

=46rom RFC 4462, the "gssapi-with-mic=E2=80=9D and = =E2=80=9Cgssapi-keyex=E2=80=9D auth methods were added here: https://github.com/netconf-wg/ssh-client-server/commit/ea518a6d= 7accc1cda656a5d1bc1300abf1c62f5a

It would be great if you could verify these = additions.  I=E2=80=99m not myself configuring any SSH clients or = servers, and thus the configuration-formulations are purely academic = based on my reading of the RFCs.

Additionally, in ietf-ssh-server, the whole = "client-authentication=E2=80=9D container, especially its = "supported-authentication-methods=E2=80=9D and =E2=80=9Cusers=E2=80=9D = descendent nodes, seem less than ideal.  Have you been using these = trees, do them seem to be formulated correctly?


For a robust and = extendible solution, why not use an identityref leaf-list with all the = methods as identities? One could then simply add new ones with specific = "if-feature" statements.

An = identityref seems reasonable, could you propose a snippet of YANG for = it?

That said, it seems equally possible = for a future module to augment-in a new leaf under the = "supported-authentication-methods=E2=80=9D container...

Right, that would solve the = problem, too. So you can keep it the way it is, up to you which solution = you prefer. Not sure why I did not think of augments first but = identityrefs. But identityrefs are much more general so the = implementation should probably depend on whether these authentication = methods are to be used only for this single purpose or not.

Either way is fine with me. =  As the module is in WGLC currently, it would be good if others = could express an option...

Anyone?



- ietf-netconf-server, grouping = netconf-server-grouping/client-identity-mappings

The "if-feature" on this container is strange. The practical = problem is that if one wants to support certificates only for TLS, both = one of the TLS features and "ssh-x509-certs" must be enabled. This then = results in the container being defined for both SSH and TLS so there is = no way to support it only for TLS or SSH.

Yes, granular features would be nice.  This issue is = tracked here: https://github.com/netmod-wg/yang-next/issues/82 <https://github.com/netmod-wg/yang-next/issues/82>. =  A possible fix would be to enable features on a per-XPath basis, = perhaps using the =E2=80=9Cnode-tags=E2=80=9D draft going on in NETMOD. =   Do you have a proposal?

BTW, = shouldn=E2=80=99t the =E2=80=9Cif-feature=E2=80=9D statement have an = =E2=80=9Cor=E2=80=9D (not an =E2=80=9Cand=E2=80=9D) between the two = major expressions?

Yes, I = think "or" fits much better. I just was not sure whether there is not a = specific reason why "and" was chosen.

OLD:        "(tls-listen = or tls-call-home) and (sshcmn:ssh-x509-certs)=E2=80=9D;
NEW:=        "tls-listen or tls-call-home = or sshcmn:ssh-x509-certs";

Well, this is no good either = because now ANY of those features are enabled, the certificates will be = supported for BOTH TLS and SSH. What should be possible to support is = X509 certificates for SSH, TLS, or both. That would require some more = remodeling of "netconf-server-grouping", not just an "if-feature" = update.

But = I wasn=E2=80=99t trying to fix your original issue.  As mentioned, = there is a YANG-next issue and the best that consuming modules can do is = to 1) enable all the features defined in these modules and 2) augment-in = =E2=80=9Cuse=E2=80=9D-specific feature statements where the groupings = are used.

My OLD/NEW update is = trying to correct a logic error.  I believe the new formulation is = correct.  It could be expanded to;

(tls-listen or = tls-call-home)
or 
= ( (ssh-listen or ssh-call-home) and sshcmn:ssh-x509-certs)

But I don=E2=80=99t think "(ssh-listen or ssh-call-home)=E2=80=9D is needed, as = certainly one would be true when "sshcmn:ssh-x509-certs=E2=80=9D is = enabled, right?



K.

= --Apple-Mail=_BE7172E0-9998-4617-AB58-ECF3D7C24285-- From nobody Mon Apr 19 13:30:26 2021 Return-Path: <01000178ebd39133-87ef25f3-1047-4f02-b5fb-706e82e7c02a-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 194BD3A42C9; Mon, 19 Apr 2021 13:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 LuV9oZMK6ceu; Mon, 19 Apr 2021 13:30:19 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56673A42CB; Mon, 19 Apr 2021 13:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618864214; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=yqj5reR6NtpAzNmulJ+pDfaD+zZeIQHVOlyQIBwCTiI=; b=Jb0HblzpZ+4Ix6OCziHWW8KsAqBantl506hTg/iJqA7Q6X6GcNpR7Fk5v6eNeWw4 nVEt/BS86u+GTokgWoiVVxfS4zbOGWRmxn9t57HKFzdXi9pT1RKMWbM3c/qozfk1hjB 9/ZacsfpGMZ6H29xLxO+ZbFpCVAx/ESMXF9/U2tc= 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 In-Reply-To: <161796231010.8005.7390142571009530431@ietfa.amsl.com> Date: Mon, 19 Apr 2021 20:30:14 +0000 Cc: YANG Doctors , draft-ietf-netconf-tcp-client-server.all@ietf.org, last-call@ietf.org, "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000178ebd39133-87ef25f3-1047-4f02-b5fb-706e82e7c02a-000000@email.amazonses.com> References: <161796231010.8005.7390142571009530431@ietfa.amsl.com> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.19-54.240.48.110 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-tcp-client-server-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 20:30:24 -0000 Hi Lada, Thank you for your review! Below are responses to your comments. K. > Reviewer: Ladislav Lhotka > Review result: Ready with Issues >=20 > The modules are well designed and nicely documented, both in the = descriptions > and text of the Internet-Draft. ;) > **** Comments >=20 > - Sections 2.1.4, 3.1.3, 4.1.3: the sentence 'The "..." module does = not contain > any protocol-accessible nodes.' is misleading in that the modules do = define > data nodes that are intended to be protocol accessible after the = corresponding > grouping is used. I know this is a part of the NETCONF/YANG lingo, but = another > formulation that clearly says what's going on might be preferable. Fair enough. How about this? The "ietf-tcp-..." module does not itself define any protocol-accessible nodes. This module defines only "grouping" statements that are used by other modules to instantiate protocol-accessible nodes. > - Sections 2.2, 3.2 and 4.2: the XML snippets use document elements > "tcp-common", "tcp-client" and "tcp-server", but these containers are = not > defined in the corresponding modules. This is confusing, my suggestion = is to > rewrite the examples in the JSON representation where no such = top-level node is > necessary. Indeed, and my validation script even takes the special step to convert = the groupings to containers in order for the validation to succeed. In = other modules, I created a =E2=80=9Cfoobar-usage.yang=E2=80=9D module to = instantiate the grouping statements. Hmmm, I was about to create the JSON, but realized that it would be = easier to strip out the first-and0-last lines from the XML examples. I = understand that they're not a valid XML documents, but snippets have = been used before=E2=80=A6 FWIW, all the examples are still validated, so there=E2=80=99s otherwise = no loss in correctness. >=20 > - What is the purpose of "tcp-connection-grouping" if it only uses > "tcp-common-grouping" and nothing else? Why cannot = "tcp-common-grouping=E2=80=9D be used directly? I added this comment: Whilst this grouping appears to not add any value beyond that given by "tcp-common-grouping", it is defined so as to provide space for a future peer module (e.g., "tcp-system-grouping" that defines = additional configuration nodes used to configure a TCP stack at an operating system level. Makes sense? > - The "local-port" parameter defined in ietf-tcp-client seems dubious = from the > security viewpoint in that fixing the source port makes it easier for = attackers > to steal the connection (see RFC 6056). Interesting read. But note that the RFC regards primarily cleartext = protocols. An axiom in security circles is =E2=80=9Cobscurity is not = security=E2=80=9D, i.e., randomizing client ports to make off-path = guessing harder is not much of a win. =20 In our case, and pretty much every IETF protocol now, a secure transport = layer is used, and having a predictable 5-tuple can greatly reduce the = attack-surface in firewall rulebases. As it stands, it=E2=80=99s configuration enabled by an optional feature = (your next comment) and, besides, the wildcard values (e.g., =E2=80=9C0=E2= =80=9D) may configured, enabling [potentially-random] operating-system = selected values - so no harm? > If the feature > "local-binding-supported" is needed at all, I'd suggest to mention = this in > Security Considerations. =E2=80=9CNeeded=E2=80=9D is an interesting take. My feeling is that = the model is incomplete otherwise. =46rom a Security Considerations = perspective, I=E2=80=99d like to put something like: =E2=80=9CImplementations are RECOMMENDED to implement the = 'local-binding-supported=E2=80=99 feature for cryptographically-secure = protocols so as to reduce to attack surface presented by firewalls.=E2=80=9D= Is that what you had in mind? If nothing else, having such a statement = in the draft would certainly catch the eye of the SecDir reviewer. = Thoughts? > - The module ietf-tcp-client uses the placeholder "RFC AAAA", which is = not > defined in the Editorial Note. Fixed. > **** Nits >=20 > - RFC 7950 is cited repeatedly (6 times) in a general context, e.g. = whenever > YANG 1.1 is mentioned. It should suffice to use the citation at the = first > appearance. All but one citation removed. > - sec. 1.3: s/in compliant/is compliant/ Fixed (in all the drafts!) > - in 3 places: s/illustatrating/illustrating/ Fixed (in all the drafts!) Thanks again! K. From nobody Mon Apr 19 14:39:57 2021 Return-Path: <01000178ec1343cb-74c9995e-8043-4e49-aa81-9da0fb07045b-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 5CD5D3A4557 for ; Mon, 19 Apr 2021 14:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 QcX7863byJTs for ; Mon, 19 Apr 2021 14:39:50 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B552F3A4555 for ; Mon, 19 Apr 2021 14:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618868389; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=li0IllkuxUKVdvWyd0WNT/XXSOmoWn+f48quBFxAkVs=; b=MwNVP9DUEjj+qU2oALArIa9PaWcX5kaQTxmHaDmUqMjwYlFNB9UBwxtvJI9ZHScD QHX4bQSWrbtycGv2XV+JL8HtOvbxI5QDjn21MgsGTcIoXBGWDUjg6zMdjjUZdLQ9flv 8U6di4MUDZYrYvzEeO10YY8LjIQ9Zf6Pzbi7oUME= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_D9615FD7-14A6-4515-8599-9C0EBA4C7EF9" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 19 Apr 2021 21:39:48 +0000 References: To: "netconf@ietf.org" In-Reply-To: Message-ID: <01000178ec1343cb-74c9995e-8043-4e49-aa81-9da0fb07045b-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.19-54.240.48.93 Archived-At: Subject: [netconf] Capability-fetching mechanisms X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 21:39:55 -0000 --Apple-Mail=_D9615FD7-14A6-4515-8599-9C0EBA4C7EF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear WG, One of the outcomes from =E2=80=9Chttps-notif=E2=80=9D presentation = during the NETCONF 110 session was to what extent all the notif (e.g., = https, udp, etc.) drafts should define their own capability-fetching = mechanism, or use the mechanism defined by the = "data-export-capabilities=E2=80=9D draft. As authors, Mahesh and I discussed some of the PROs and CONs of the = approaches as follows: PROs (for having a shared-mechanism): Enables a common mechanism spanning multiple notif transports to exist=20= CONs (against having a shared mechanism): Entails each receiver also needing to be a NETCONF and/or RESTCONF = server Whereas a notif-specific solution can be optimized on a per-protocol = basis. FWIW, if RC, the receiver COULD minimally support *just* the single GET = request (i.e., not a complete RC server) Still, networking/firewall would have to support the outbound NC/RC = flow, in addition to the base notification flow Potentially extends the number of capabilities to be more than minimally = necessary e.g., the current "data-export-capabilities=E2=80=9D modules define = dozens of capabilities supporting RFC 8639 and RFC 8641 that are not = needed for https-notif, when RFC 8639 is not in use. HTTPS-Notif seems to need only three capabilities: What encodings are supported (json, xml, binary) If the RFC 8639 state machine is supported. If bundled messages is supported. Presumably, UDP-Notif would similarly have a small set of capacities. In fact, it may be less, as UDP may be unable to support RFC 8639 Thoughts? Kent and Mahesh // as authors --Apple-Mail=_D9615FD7-14A6-4515-8599-9C0EBA4C7EF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = WG,

One of the = outcomes from =E2=80=9Chttps-notif=E2=80=9D presentation during the = NETCONF 110 session was to what extent all the notif (e.g., https, udp, = etc.) drafts should define their own capability-fetching mechanism, or = use the mechanism defined by the "data-export-capabilities=E2=80=9D = draft.

As authors, = Mahesh and I discussed some of the PROs and CONs of the approaches as = follows:

  • PROs (for having a = shared-mechanism):
    • Enables a common = mechanism spanning multiple notif transports to = exist 

  • CONs (against having a shared mechanism):

    • Entails each receiver also = needing to be a NETCONF and/or RESTCONF server
      • Whereas a notif-specific solution can be optimized on a = per-protocol basis.
      • FWIW, if RC, the receiver COULD = minimally support *just* the single GET request (i.e., not a complete RC = server)
      • Still, networking/firewall would have to = support the outbound NC/RC flow, in addition to the base notification = flow

    • Potentially = extends the number of capabilities to be more than minimally = necessary
      • e.g., the = current "data-export-capabilities=E2=80=9D modules = define dozens of capabilities supporting RFC 8639 and RFC 8641 that are = not needed for https-notif, when RFC 8639 is not in use.
        • HTTPS-Notif seems to need only three = capabilities:
          1. What encodings are = supported (json, xml, binary)
          2. If the RFC 8639 = state machine is supported.
          3. If bundled messages is = supported.
        • Presumably, UDP-Notif would similarly = have a small set of capacities.
          • In = fact, it may be less, as UDP may be unable to support RFC = 8639


Thoughts?

Kent and Mahesh  // = as authors


= --Apple-Mail=_D9615FD7-14A6-4515-8599-9C0EBA4C7EF9-- From nobody Mon Apr 19 15:23:31 2021 Return-Path: <01000178ec3aebdf-1c5e3f62-5432-4d07-80d4-85480626a545-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 316EF3A47AC; Mon, 19 Apr 2021 15:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 PFJrbmey_Hpi; Mon, 19 Apr 2021 15:23:20 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C2C3A4724; Mon, 19 Apr 2021 15:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618870987; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=H3FmrSu+Ltv2VchDpsHx3vXZOzPWkinJM3eZeXMg+fs=; b=GGcLaH+liAAOdusH7HGVAfLx9uqlwPGxbRWhMNHxpzEKZ2WeO2udHnWGkR50XW8X Ns7smQ/mGMfqdyIgqODSaemfFLhpkn6QLZG7aWjapF5s3o7i/e7QGqGqe8uasSblKIC oNe7uWngS9gBn/s8s00KD0CYgLcSYAE8/6l5vEvA= 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 In-Reply-To: <161821556350.10432.14910369341748800490@ietfa.amsl.com> Date: Mon, 19 Apr 2021 22:23:07 +0000 Cc: YANG Doctors , last-call@ietf.org, "netconf@ietf.org" , draft-ietf-netconf-http-client-server.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <01000178ec3aebdf-1c5e3f62-5432-4d07-80d4-85480626a545-000000@email.amazonses.com> References: <161821556350.10432.14910369341748800490@ietfa.amsl.com> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.19-54.240.48.92 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-http-client-server-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 22:23:25 -0000 Hi Lada, Thank you for your review! Below are responses to your comments. K. > On Apr 12, 2021, at 4:19 AM, Ladislav Lhotka via Datatracker = wrote: >=20 > Reviewer: Ladislav Lhotka > Review result: Ready with Nits >=20 > The document defines two YANG modules - ietf-http-client and = ietf-http-server - > that belong to a relatively complex set of modules. The modules are = well > designed and nicely documented, both in the descriptions and document = text. :) > **** Comments >=20 > - Sections 2.1.3 and 3.1.3: the sentence 'The "..." module does not = contain any > protocol-accessible nodes.' is misleading in that the modules do = define data > nodes that are intended to be protocol accessible after the = corresponding > grouping is used. I know this is a part of the NETCONF/YANG lingo, but = another > formulation that clearly says what's going on might be preferable. I fixed this when I addressed the same comment made in the = =E2=80=9Ctcp-client-server=E2=80=9D draft. > - Sections 2.2 and 3.2: the XML snippets use document elements = "http-client" > and "http-server", but these containers are not defined in the = corresponding > modules. This is confusing, my suggestion is to rewrite the examples = in the > JSON representation where no such top-level node is necessary. Same solution as for the =E2=80=9Ctcp-client-server=E2=80=9D draft, = which is to simply remove the first and last lines, for the non-existent = =E2=80=9Ccontainer=E2=80=9D statement. Update: I was going to proactively-apply the same solution to the = =E2=80=9Cssh=E2=80=9D and =E2=80=9Ctls=E2=80=9D drafts, but I couldn=E2=80= =99t because the top-level element defines additional prefixes. This is = where your =E2=80=9CJSON=E2=80=9D idea could help, though, for some = reason, having a mix of XML/JSON in the suite of drafts is off-putting = to me. We could convert all the examples to JSON, but that=E2=80=99s a = fair amount of work too=E2=80=A6 =20 How about adding an XML-comment indicating that the top-level element = doesn=E2=80=99t really exist? > - Placeholders BBBB, CCCC and EEEE are defined in Editorial Note but = never used Fixed. > **** Nits >=20 > - RFC 7950 is cited repeatedly (4 times) in a general context, e.g. = whenever > YANG 1.1 is mentioned. It should suffice to use the citation at the = first > appearance. Fixed. Also in the =E2=80=9Cssh=E2=80=9D and =E2=80=9Ctls=E2=80=9D = drafts. K. From nobody Mon Apr 19 16:20:01 2021 Return-Path: <01000178ec6ee506-50ea847c-93a5-4e6b-a99a-02e85a2e74fc-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 E72EF3A48DE for ; Mon, 19 Apr 2021 16:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 1LyvitcHFBrC for ; Mon, 19 Apr 2021 16:19:55 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292E23A48DC for ; Mon, 19 Apr 2021 16:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618874394; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=wKn3HaTD0J3rQ44uoaFH37IuUvKbTCysZfBC2JWn914=; b=X+cZGxP2U6/7neO6XLX7rS5S6zX132j76Z2LHJQOg6Yfx0y6mq4Pwo5oIftP4s+Y GuWjxounu8qAsRYVKahq0ZMNqDJFi79phjIzPgaHgx0j2K0+6SeiIDn69YEIFpBKrZ9 S1AuBEphy96KBroZLpp0Pf8rK5eTpalYFO4rawEw= From: Kent Watsen Message-ID: <01000178ec6ee506-50ea847c-93a5-4e6b-a99a-02e85a2e74fc-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2A4AFC1B-C92E-4890-B7E2-1AB73E67E10C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 19 Apr 2021 23:19:53 +0000 In-Reply-To: Cc: Mahesh Jethanandani , "netconf@ietf.org" To: Dhruv Dhody References: X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.19-54.240.48.90 Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-tls-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 23:20:00 -0000 --Apple-Mail=_2A4AFC1B-C92E-4890-B7E2-1AB73E67E10C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dhruv, Thank you for your review! Below are responses to your comments. K. > On Apr 13, 2021, at 4:42 AM, Dhruv Dhody wrote: >=20 > Hi Mahesh, WG, >=20 > I have reviewed the draft. The PCE YANG uses these groupings and I am = happy to see the WG make progress on this I-D. :) > Few comments - > - Both abstract and introduction say that the first module is the TLS = client whereas the first module defined in this I-D is the TLS common. Fixed (also fixed in other drafts where the issue arose) > - I am wondering if anything needs to be done for the older versions = of TLS which are made historic. The use of features helps, is there any = other guidance that needs to be given? We could set the =E2=80=9Cstatus=E2=80=9D to =E2=80=9Cdeprecated=E2=80=9D.= That said, it's one thing to say that a protocol is deprecated and = another to say that the configuration for a still somewhat widely-used = deprecated-protocol is deprecated=E2=80=A6thoughts? > - Why is there no identity for TLS 1.3? Because the draft has been a work in progress for longer then TLS 1.3 = ;) Just added an identity for 1.3. > - For the feature tls-1_3, the description says 1.2 Fixed! > - Copyright year in the YANG modules is still 2020 Fixed (in all drafts) > - Authors in the YANG module is inconsistent with the I-D Correct, Gary Wu helped with the YANG module only (in the =E2=80=9Cssh=E2=80= =9D draft also). For both drafts, I=E2=80=99ve created a new = =E2=80=9CContributors=E2=80=9D section to better call out his = contribution. > - Reference used in YANG (FIPS PUB 180-4) needs to be added in the I-D = as well.=20 Reference added. >=20 > Thanks! > Dhruv Thanks! K. --Apple-Mail=_2A4AFC1B-C92E-4890-B7E2-1AB73E67E10C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dhruv,

Thank you for your review!

Below are responses to your comments.

K.


On Apr 13, 2021, at 4:42 AM, = Dhruv Dhody <dhruv.ietf@gmail.com> wrote:

Hi= Mahesh, WG,

I have reviewed the draft. The = PCE YANG uses these groupings and I am happy to see the WG make progress = on this I-D.

:)


Few comments -
- Both abstract and introduction = say that the first module is the TLS client whereas the first module = defined in this I-D is the TLS common.

Fixed (also fixed in other drafts where the issue = arose)


- I am = wondering if anything needs to be done for the older versions of TLS = which are made historic. The use of features helps, is there any other = guidance that needs to be given?

We could set the =E2=80=9Cstatus=E2=80=9D to = =E2=80=9Cdeprecated=E2=80=9D.  That said, it's one thing to say = that a protocol is deprecated and another to say that the configuration = for a still somewhat widely-used deprecated-protocol is = deprecated=E2=80=A6thoughts?



- Why is there no identity for TLS 1.3?

Because the draft has been a work in progress for = longer then TLS 1.3  ;)

Just = added an identity for 1.3.


- For the feature tls-1_3, the description says 1.2

Fixed!


- Copyright year in the YANG modules is still 2020

Fixed (in all drafts)


- Authors in = the YANG module is inconsistent with the I-D


Correct, Gary Wu helped with = the YANG module only (in the =E2=80=9Cssh=E2=80=9D draft also). =  For both drafts, I=E2=80=99ve created a new =E2=80=9CContributors=E2= =80=9D section to better call out his contribution.


- Reference = used in YANG (FIPS PUB 180-4) needs to be added in the I-D as well.

Reference added.



Thanks!
Dhruv

Thanks!

K.


= --Apple-Mail=_2A4AFC1B-C92E-4890-B7E2-1AB73E67E10C-- From nobody Mon Apr 19 16:34:20 2021 Return-Path: <01000178ec7bfedf-5b8a2940-2fdd-42f5-ae43-27277d991769-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 AD4F63A4958; Mon, 19 Apr 2021 16:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 qJWEwNQg4DaP; Mon, 19 Apr 2021 16:34:14 -0700 (PDT) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24AA3A4956; Mon, 19 Apr 2021 16:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618875252; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=pyc1GRNP7ZmFNO1wPgqEA6opmhvzNnnKO6FDhPQ/X4s=; b=LTe12lzuZQMh/0cm0lvVJ+kbohPwCa2gPZOnj1kDJWaFqgkAgwTJzlMCvQknQk+X Zv5EmuyOmcry77i2quUlY7T2jVEN+G2GUBOsqaOw4UrINm4fte7sSAt9i9FlFrs6bXh /4Ji3K+91WlbY9G9+jLojns+TysKxPCRM0h3Xs7w= 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 In-Reply-To: <20210416115004.fqhitq6jofc6vjih@anna.jacobs.jacobs-university.de> Date: Mon, 19 Apr 2021 23:34:12 +0000 Cc: "netconf@ietf.org" , YANG Doctors Content-Transfer-Encoding: quoted-printable Message-ID: <01000178ec7bfedf-5b8a2940-2fdd-42f5-ae43-27277d991769-000000@email.amazonses.com> References: <161045360252.14510.16755799701987783827@ietfa.amsl.com> <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com> <20210416115004.fqhitq6jofc6vjih@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.19-54.240.48.95 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 23:34:19 -0000 Hi Juergen, Whittling out things resolved... K. >=20 >> - Does it make sense to have a new notation like >>>=20 >>> | The diagram above uses syntax that is similar to but not >>> | defined in [RFC8340]. >>>=20 >>> or shall this simply become regular text? >>=20 >> I find using tree-diagram like notation for features, identities, and = typedefs helpful, especially in showing the =E2=80=9Cif-feature=E2=80=9D = constraints and hierarchical relationships between items. I recommend = adding these enhancements to RFC 8340. It would be helpful if someone = could whip up an I-D so these documents could reference the I-D instead = of having the "The diagram above uses syntax that is similar to but not = defined in [RFC8340]=E2=80=9D language. >>=20 >> That said, I also used a "rfc8340-like" diagram to list all the = groupings in a module. It seems like the consistent thing to do, but I = can=E2=80=99t imagine the RFC 8340 being updated to support that output, = so I replaced that diagram, with a normal "xml2rfc" list, in the entire = suite of drafts. >=20 > I am sorry, I should have been clearer. My comment did not concern the > diagrams but the mere fact that you have >=20 > | The diagram above uses syntax that is similar to but not > | defined in [RFC8340]. >=20 > instead of simply >=20 > The diagram above uses syntax that is similar to but not > defined in [RFC8340]. >=20 > and this is really an editorial nit if at all. The diagram itself I > like, it would be nice to have them in RFC 8340bis. Ah, now I understand, you mean to remove the XML2RFC v3 =E2=80=9Caside=E2=80= =9D? I agree that it renders poorly in plain-text, but it renders = inside a pretty-box for HTML and PDF. Thoughts? Yes, the diagrams would be a nice addition to an 8340bis. Also, I = don=E2=80=99t know if you noticed, but the =E2=80=9CData Model = Overview=E2=80=9D section I created in all these drafts is highly = mechanical=E2=80=A6something that could be mostly automated=E2=80=A6perhap= s a good student project? ;) >>> - I wonder why this is a SHOULD and not a MUST: >>>=20 >>> "Identifies the symmetric key's format. Implementations >>> SHOULD ensure that the incoming symmetric key value is >>> encoded in the specified format."; >>>=20 >>> This statement shows up several times when the key-format identities >>> are used. I wonder what this means to an implementer. If I receive a >>> key format (say one-symmetric-key-format) and a corresponding blob >>> of data, do I have to decode this to see whether the format works >>> out? If later the key-format is changed to something else (lets say >>> octet-string-key-format), do I reject such a change or is it OK as >>> long as the binary data I have would be a valid value given the new >>> format? Perhaps this is implementation specific? Well, since we deal >>> with keys, ... >>=20 >> It currently a "SHOULD=E2=80=9D because some implementations may = assume that clients always configure perfect values, and so it becomes = squishy as to if they MUST. If a server fails to validate the base64 = contents (which are outside YANG validation) as they=E2=80=99re being = applied, then the server may run into nasty exceptions when needing to = use the value at runtime. A nice system will decode the base64 values = and verify that they contain valid values during the commit process. >>=20 >> Make sense? - leave as SHOULD okay? >=20 > Thanks for the explanation. I am not religious about SHOULD vs MUST > here. I=E2=80=99ll leave as a SHOULD then. > I have browsed through the diffs and they look good. I did not do > another full review again. Thanks and Ack. K. From nobody Mon Apr 19 18:11:22 2021 Return-Path: <01000178ecd4d350-f50aba60-953e-4803-abc7-acc14adc7355-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 6B3903A0C04; Mon, 19 Apr 2021 18:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 1Jhfip6ve4U2; Mon, 19 Apr 2021 18:11:15 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FBB3A0C03; Mon, 19 Apr 2021 18:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618881074; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=xN6SlisJwPhDj8GCc3RTlhDkCCTnRHJEFx0a3F38IQk=; b=Gdrr6YJZ7TaM+v5VV2mkLSbuK5sbufGYuvr05YH1D7U0bcCdi0g4VeKgp6czt7Fi gWy489jCV+jFRdC/eEMqA7RKkFBJH54DAG2E9a7srMzINFr/6Sc7PzYtZNsDjNJ0dli A+rME6kdqoJkCIx274n39OEZdbeTjW5OCJ/mw34A= 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 In-Reply-To: <20210416121527.z7z42ptkhxc734vy@anna.jacobs.jacobs-university.de> Date: Tue, 20 Apr 2021 01:11:14 +0000 Cc: YANG Doctors , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000178ecd4d350-f50aba60-953e-4803-abc7-acc14adc7355-000000@email.amazonses.com> References: <161047687248.13931.17900123352005904827@ietfa.amsl.com> <010001778e67c4e0-c179290b-6eba-46df-b17f-ec474c44783c-000000@email.amazonses.com> <20210416121527.z7z42ptkhxc734vy@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.20-54.240.48.93 Archived-At: Subject: Re: [netconf] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 01:11:20 -0000 Hi Juergen, Whittling out things resolved. K. >>> Reviewer: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder >>> Review result: Ready with Issues >>>=20 >>> The crypto modules aim at providing a flexible reusable = infrastructure >>> of groupings for modeling cryptographic keys and related concepts. = The >>> flexibility of the definitions provided of course comes with a = certain >>> amount of complexity. >>>=20 >>>> =46rom a YANG perspective, draft-ietf-netconf-trust-anchors-13.txt = is in >>> a good and close to publish state (a couple of minor issues left). = I >>> also tried to understand what is being modeled here and hence I also >>> have some questions concerning the concepts modeled and I hope these >>> are easy to answer/resolve as well. >>>=20 >>> - I have compiled the YANG modules using yanglint 0.16.105. >>>=20 >>> - The prefix 'ts' is rather short, the set of two letter prefixes is >>> rather small limited. This comment also applies to the other >>> documents, crypto-types uses 'ct. Perhaps this is not a problem >>> since collisions can be handled but if we go for rather short >>> prefixes, we will have to exercise the collision resolution. (I see >>> that 'ct' has already been used by ietf-complex-types, RFC 6095.) A >>> possible alternative could be to use sec-ct, sec-ts, sec-ks, ...). >>=20 >> Ugh (me, whenever a naming-discussion comes up ;) >>=20 >> I don=E2=80=99t know why prefixes are registered, as the prefix = is defined at the top of each module. The only value I see is not = syntactic but rather for consistency, to aid human readability across = disconnected sets of modules. >>=20 >> Prefixing the prefix with =E2=80=9Csec-=E2=80=9C may work for the = trio of drafts you just reviewed, but it seems undesirable when getting = to the client-server drafts, as they're more *protocol* oriented. If = =E2=80=9Cks=E2=80=9D and =E2=80=9Cts=E2=80=9D aren=E2=80=99t taken, then = maybe we claim =E2=80=9Cfirst mover=E2=80=9D advantage? If not, then = maybe =E2=80=9Ckstore=E2=80=9D and =E2=80=9Ctstore=E2=80=9D might be = meaningful fallbacks? Assuming we claim =E2=80=9Cfirst mover=E2=80=9D = advantage for =E2=80=9Cks=E2=80=9D and =E2=80=9Cts=E2=80=9D, then we = just need to handle =E2=80=9Cct=E2=80=9D, which maybe could be = =E2=80=9Cctypes=E2=80=9D or =E2=80=9Ccryptypes=E2=80=9D or =E2=80=9Cct2=E2= =80=9D? So, 1) prefix the trio or 2) claim first-mover advantage on two = and figure out something for =E2=80=9Cct=E2=80=9D? =E2=80=A6or maybe 3) = keep =E2=80=9Cct=E2=80=9D also noting that a) =E2=80=9CSHOULD NOT=E2=80=9D= is not a =E2=80=9CMUST NOT=E2=80=9D (in the text below), b) my = =E2=80=9Crant=E2=80=9D might have some merit, and c) short and terse is = nice (per your next comment). >>=20 >=20 > I suggest you think over it and pick whatever you think seems to be a > good solution. ;-) I prefer to do nothing and push conflict resolution to the front. I = understand that this is against the SHOULD NOT at the end of RFC 8407 = Section 4.2. In this case, I feel that continuing to use =E2=80=9Cct=E2=80= =9D, =E2=80=9Cts=E2=80=9D and =E2=80=9Cts=E2=80=9D is best. If there = were a convenient *good* alternative, I=E2=80=99d do it, but I don=E2=80=99= t think there is, and it=E2=80=99s not worth trying to avoid a conflict = with an =E2=80=9Cexperimental=E2=80=9D RFC from a decade ago that I=E2=80=99= ve never heard of. >>> - Is the feature truststore-supported really needed? Does the YANG >>> library not already provide the information whether a module has >>> been implemented or just imported to access type and grouping >>> definitions? >>=20 >> This was discussed before. The bottom of Section 2.1.4 says: "The = reason for why the "truststore-grouping" exists separate from the = protocol-accessible nodes definition is to enable instances of the = truststore to be instantiated in other locations, as may be needed or = desired by some modules.=E2=80=9D. Case in point, the MacOS =E2=80=9CKeyc= hain Access=E2=80=9D utility maintains both system-level and user-level = trust anchors. [UPDATE: you had a similar comment in the keystore = draft, which you self-resolved there and then said to ignore this = comment. Just the same, let=E2=80=99s ensure the drafts are clear.] >=20 > This explanation gives a reason why there are groupings. My question > concerned the feature truststore-supported. Is the YANG library not > already providing the information whether a module has been > implemented or only used for getting access to definitions? In RFC > 8525, you have a list of modules implemented and a list of modules > used for import only. My question is does feature truststore-supported > mean the same as the module shows up in the implemented module set in = the YANG library? Okay, I see. Yes, the two things mean the same thing, but there is a = need still, which is that =E2=80=9Cif-feature=E2=80=9D statement = expression cannot reference the conformance of a module in YL, which is = compounded by the fact that how it is expressed differs from RFC 7895 = and RFC 8525. > I have looked through the diffs, looked all good to me. Thanks. K. From nobody Mon Apr 19 18:28:52 2021 Return-Path: <01000178ece4d8fd-09010867-cbff-486e-b598-3653e944b833-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 602403A0D39; Mon, 19 Apr 2021 18:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 X5psgx2qtx6v; Mon, 19 Apr 2021 18:28:45 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682053A0D2D; Mon, 19 Apr 2021 18:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618882124; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=Bq8iYRT9gnc+njqhiTBSJyRd5QhZ6GdYCzaYc6icsnM=; b=gVqlzRK4YiLXWGA7u/XWqI268YJqGzkh4tTqXZfQ0m+ifDM2LkJP9bHbDVaWRKCq KPyK83fb5Kn+P8Uh/3uBC/MdulhlKAsj65N5w2qI2LeZWRNIVbcPGhWy7SfSqBSbeJl vR7szPOQGsSyoWI2hz8p974yfCa0z4TUu7K0Dil4= 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 In-Reply-To: <20210416123749.246d6irnd3oso3x4@anna.jacobs.jacobs-university.de> Date: Tue, 20 Apr 2021 01:28:44 +0000 Cc: YANG Doctors , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000178ece4d8fd-09010867-cbff-486e-b598-3653e944b833-000000@email.amazonses.com> References: <161064362767.26403.10249622617283363882@ietfa.amsl.com> <010001778e68398d-c2bff7b8-4c4e-4f30-a962-1ce39e2ece13-000000@email.amazonses.com> <20210416123749.246d6irnd3oso3x4@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.20-54.240.8.33 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-keystore-20 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 01:28:50 -0000 Hi Juergen, Likewise trimming to the essential parts. K. >>> - Is the feature keystore-supported really needed? Does the YANG >>> library not already provide the information whether a module has >>> been implemented or just imported to access type and grouping >>> definitions? OK, I know see that this is used to make definitions >>> conditional, hence it makes sense. This means that my comment on >>> truststore-supported in the other review can be ignored, I found >>> the answer. >>=20 >> Please see my response to your comment in that draftb >>=20 >=20 > See also my comment on the other document. My question was whether > this bit can already be picked up from the YANG library. Right, and I did just reply that whilst the two point to the same same, = only one can be used in =E2=80=9Cif-feature=E2=80=9D statement = expressions, which is what is needed. >=20 >> BTW, b >=20 > I think this is better. It took me while to determine what text got clipped above which you this = is better. Let me clarify, you think that it would be better to both: OLD; keystore-supported NEW: central-keystore-supported *and* OLD: =E2=80=A6 the keystore, when this module is implemented NEW: =E2=80=A6 the central keystore, when this module is implemented Correct? >>> - Section 4.3 talks about _highly_ restricted access mechanisms and >>> _highly_ authorized clients and I am usually a bit confused what >>> _highly_ means. But I am YANG doctor, not a security reviewer. ;-) >>=20 >> Trying to say that, e.g., the NACM should only allow a "crypto = officer" access to the MKb >=20 > So is NACM the 'highly restricted access mechanisms'? Should it be >=20 > OLD > highly restricted access mechanisms SHOULD >=20 > NEW > access control mechanisms like NACM SHOULD Replaced. Better, thanks! > OLD > highly authorized clients >=20 > NEW > authorized clients NEWEST: ...only to the most trusted authorized clients Ok? > My point is that "highly" simply does not mean anything (to me). Point taken, =E2=80=9Chighly=E2=80=9D doesn=E2=80=99t mean much. > I browsed the diff, the changes look good to me. Thanks, K. From nobody Mon Apr 19 22:48:43 2021 Return-Path: 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 29FF03A0EF9 for ; Mon, 19 Apr 2021 22:48:42 -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 mnTC3tOq3NO8 for ; Mon, 19 Apr 2021 22:48:37 -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 ECA853A0EFA for ; Mon, 19 Apr 2021 22:48:36 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 112C56007C; Tue, 20 Apr 2021 07:48:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1618897713; bh=eEb0IiJgmnrA/JLOOtlRl467cj4E8GFpB9HSLhPiIh4=; h=From:In-Reply-To:Date:Cc:To:Subject; b=nCnPEcMNrwZbijaQHWTAGn6oBT4ha2+awFlRFF9wZTuiDHw76wLMAgUoW2pKCm0gG xqBxqwFPN2fJP5Q2Aox6K5/vScjdOD66/wILDomjXresPEjUSxSw0KN0Ri4xw10gtT 85LrV5zNx9EwbAZ4Fg1iaT5lx5X5mbyaq7YgLDvk= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <01000178eb3f0c88-bfd76315-200a-4bcb-982f-8700be82ef77-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Tue, 20 Apr 2021 07:48:33 +0200 Cc: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <1104-607e6b00-3-2fba9200@222555441> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 05:48:42 -0000 Hi Kent, responses also inline. > Hi Michal, > > Please find responses below. > > K. > > > >>>>> - ietf-ssh-server, ssh-server-grouping/client-authentication/su= pported-authentication-methods> > >>>>> Since the "other" leaf-list was removed there is no way to supp= ort some other methods than those specified. I am not sure whether this= was the intention and if so, what is the reason for it? If nothing els= e, we support "interactive" authentication method but there are some ot= hers that I see no reason why they could not be used. > >>>> > >>>> It took me a bit to determine that this change happened in ssh-c= lient-server-18. > >>>> > >>>> The motivation behind the change was to align the values with th= ose defined in RFCs 4252 and 4250. > >>>> > >>>> You mention an =E2=80=9Cinteractive=E2=80=9D and =E2=80=9Csome o= ther=E2=80=9D methods - where are they defined? > >>> > >>> That is a good question. It seems no other methods are standardiz= ed but that does not mean they are not used. > >> > >> What change are you hoping to see? Is there anyway that such chan= ges could be augmented in, or must they be in the base module? > > > > Okay, so properly looking at all this, the 2 missing authentication= methods (that are supported by libssh or sshd, or example) are actuall= y standardized so I suppose you can add them directly into the YANG mod= ule. There are "keyboard-interactive" [1] (not "interactive") and "gssa= pi-with-mic" [2]. > > > > [1] https://tools.ietf.org/html/rfc4256 > > [2] https://tools.ietf.org/html/rfc4462 > > Thanks for tracking those RFCs down. > > From RFC 4256, the "keyboard-interactive=E2=80=9D auth method was add= ed here: https://github.com/netconf-wg/ssh-client-server/commit/6cc6a9e= cd0be7db01c6a1ba39ed7b32ac6310163. > > From RFC 4462, the "gssapi-with-mic=E2=80=9D and =E2=80=9Cgssapi-keye= x=E2=80=9D auth methods were added here: https://github.com/netconf-wg/= ssh-client-server/commit/ea518a6d7accc1cda656a5d1bc1300abf1c62f5a > > It would be great if you could verify these additions. I=E2=80=99m n= ot myself configuring any SSH clients or servers, and thus the configur= ation-formulations are purely academic based on my reading of the RFCs.= I am using only the "keyboard-interactive" method and only as a user, = so I do not have in-depth knowledge. However, it seems fine and should = be now configurable, thanks! Like I said, I cannot say much about the "= gssapi" methods, never used them. But they also seems fine to me. > Additionally, in ietf-ssh-server, the whole "client-authentication=E2= =80=9D container, especially its "supported-authentication-methods=E2=80= =9D and =E2=80=9Cusers=E2=80=9D descendent nodes, seem less than ideal.= Have you been using these trees, do them seem to be formulated correc= tly? We are not using them (yet) as the last draft we implemented was still = missing some features. Looking at it now, it seems okay. An improvement= I can think of is to put all the authentication methods in "users/user= " in a mandatory choice. The authentication methods would be one case, = while something like "global-config" (empty leaf, for example) would be= the other. That should allow for maximum versatility when one could co= nfigure the 'global authentication methods', enable the "client-auth-co= nfig-supported" feature to configure the recognized users, but use the = global authentication methods settings for some/all the users (not havi= ng to configure each one separately). Because that will probably be our= use-case. > > >>>>> For a robust and extendible solution, why not use an identityre= f leaf-list with all the methods as identities? One could then simply a= dd new ones with specific "if-feature" statements. > >>>> > >>>> An identityref seems reasonable, could you propose a snippet of = YANG for it? > >>>> > >>>> That said, it seems equally possible for a future module to augm= ent-in a new leaf under the "supported-authentication-methods=E2=80=9D = container... > >>> > >>> Right, that would solve the problem, too. So you can keep it the = way it is, up to you which solution you prefer. Not sure why I did not = think of augments first but identityrefs. But identityrefs are much mor= e general so the implementation should probably depend on whether these= authentication methods are to be used only for this single purpose or = not. > >> > >> Either way is fine with me. As the module is in WGLC currently, i= t would be good if others could express an option... > > Anyone? > > > > >>>>> - ietf-netconf-server, grouping netconf-server-grouping/client-= identity-mappings > >>>>> > >>>>> The "if-feature" on this container is strange. The practical pr= oblem is that if one wants to support certificates only for TLS, both o= ne of the TLS features and "ssh-x509-certs" must be enabled. This then = results in the container being defined for both SSH and TLS so there is= no way to support it only for TLS or SSH. > >>>> > >>>> Yes, granular features would be nice. This issue is tracked her= e: https://github.com/netmod-wg/yang-next/issues/82 . A possible fix would be to enable fea= tures on a per-XPath basis, perhaps using the =E2=80=9Cnode-tags=E2=80=9D= draft going on in NETMOD. Do you have a proposal? > >>>> > >>>> BTW, shouldn=E2=80=99t the =E2=80=9Cif-feature=E2=80=9D statemen= t have an =E2=80=9Cor=E2=80=9D (not an =E2=80=9Cand=E2=80=9D) between t= he two major expressions? > >>> > >>> Yes, I think "or" fits much better. I just was not sure whether t= here is not a specific reason why "and" was chosen. > >> > >> OLD: "(tls-listen or tls-call-home) and (sshcmn:ssh-x509-ce= rts)=E2=80=9D; > >> NEW: "tls-listen or tls-call-home or sshcmn:ssh-x509-certs"= ; > > > > Well, this is no good either because now ANY of those features are = enabled, the certificates will be supported for BOTH TLS and SSH. What = should be possible to support is X509 certificates for SSH, TLS, or bot= h. That would require some more remodeling of "netconf-server-grouping"= , not just an "if-feature" update. > > But I wasn=E2=80=99t trying to fix your original issue. As mentioned= , there is a YANG-next issue and the best that consuming modules can do= is to 1) enable all the features defined in these modules and 2) augme= nt-in =E2=80=9Cuse=E2=80=9D-specific feature statements where the group= ings are used. Okay, I suppose this can be done although it seems to me like a minor d= eviation (the augment solution). What is the reason for not having the = module this way out-of-the-box? > My OLD/NEW update is trying to correct a logic error. I believe the = new formulation is correct. It could be expanded to; > > (tls-listen or tls-call-home) > or > ( (ssh-listen or ssh-call-home) and sshcmn:ssh-x509-certs) > > But I don=E2=80=99t think "(ssh-listen or ssh-call-home)=E2=80=9D is = needed, as certainly one would be true when "sshcmn:ssh-x509-certs=E2=80= =9D is enabled, right? Yes, I agree with this. Regards, Michal From nobody Mon Apr 19 23:40:26 2021 Return-Path: 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 43E3B3A11E5 for ; Mon, 19 Apr 2021 23:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 YKAd2sBwFt9A for ; Mon, 19 Apr 2021 23:40:20 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884EB3A11E4 for ; Mon, 19 Apr 2021 23:40:20 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id f21so1285561ioh.8 for ; Mon, 19 Apr 2021 23:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iLUUSpdjrBg62wdvvO/8RKM1tNpApHAIXasUJKkn7Sw=; b=t2aoIZBA802n61UbG7RHlNqL/bAqADpRnSMFCYSTiEwcxk8CxpyHkvSpXiUej2cuhq KnngTikZjD7W0DugI+YJyQC4pPa8JgoEZvPAOSbbheVoHj4bSAgnrs/g9Dj2+rUDm2VF RakDl2pX2DBm44hh9hW/+lj32G6r4wgQZjXUiJSJoF4VvRuQtDhTCyypYBJi6IBlWstI TrMMsC6L0cLIwP/H0jHjY5IahMGGviuSV9siAnHxHOKS1CocGpetVfQhWlAjeUAYrZ0p GR4+bQmjvQIxOHzHmPkpSZtds1pbFXVgxnCOpqJ6hikvKhtgcx/JaRQe2zxQ7Nxdhb/7 7ouw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iLUUSpdjrBg62wdvvO/8RKM1tNpApHAIXasUJKkn7Sw=; b=ZQ5cKWcpKCd8q+LgCv3QkrwrTX0UmubQ9mdi5CT1QY/f/dfjGQdZTiH82ouxfPaYQr UBUu+J5g2cCzP25DgcGQE6O2aBkFxF8SBP8+FKHQu6MNOuIS+UVfAN80GSyHiANRqPg4 ojgZAHoAQrkr1m37LnKbhNVjsXjDJsSJbkPXl4zaG5TjOgcQFDCqYXQQVus5T4QvLEcq ndd7nYM1RPa7JERXaS+NmiEUaSqo0rzZaIEDL5lKgJtxvkO2ywdKlrmekRafy/QyZaLq WYgn1GTR8xgtiUPjPJ/gFv3dNJdl/xQ4X+uG45t1wmv3uFFOmGKmDX87h9zOl4BYZK+L 0OIA== X-Gm-Message-State: AOAM532AQQoDD1WdxeXXC1w/3MURH0slSaWiOCNhudkcoPSrN7hQ5TaO AMZ0xiokwQBX94wOs/hKgZM+7PUzDJoycb9JSzo= X-Google-Smtp-Source: ABdhPJw65B8r2vX87ETuaGSvFLjH0YOZWjWlbTykWbHylFPqu9N9GMJ055O9IZ08XionUFzS7g27Up9UlvzyAc6sufo= X-Received: by 2002:a02:c618:: with SMTP id i24mr19846803jan.15.1618900818754; Mon, 19 Apr 2021 23:40:18 -0700 (PDT) MIME-Version: 1.0 References: <01000178ec6ee506-50ea847c-93a5-4e6b-a99a-02e85a2e74fc-000000@email.amazonses.com> In-Reply-To: <01000178ec6ee506-50ea847c-93a5-4e6b-a99a-02e85a2e74fc-000000@email.amazonses.com> From: Dhruv Dhody Date: Tue, 20 Apr 2021 12:09:42 +0530 Message-ID: To: Kent Watsen Cc: Mahesh Jethanandani , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003a814705c061b898" Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-tls-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 06:40:25 -0000 --0000000000003a814705c061b898 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, > - I am wondering if anything needs to be done for the older versions of > TLS which are made historic. The use of features helps, is there any othe= r > guidance that needs to be given? > > > We could set the =E2=80=9Cstatus=E2=80=9D to =E2=80=9Cdeprecated=E2=80=9D= . That said, it's one thing to > say that a protocol is deprecated and another to say that the configurati= on > for a still somewhat widely-used deprecated-protocol is > deprecated=E2=80=A6thoughts? > > > I agree that we need to allow the configuration of older TLS versions in the YANG module. I found this comment from Ben to be useful - https://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9PymiovieA= / . I ended up putting MD5 and SHA-1 support under a feature 'deprecated'. In this case, I think just adding some text in the description around the existing features for older TLS could also do the job. Thanks for taking my comments into consideration! Dhruv --0000000000003a814705c061b898 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kent,=C2= =A0


- I am wondering if anything needs to be done for the older versions o= f TLS which are made historic. The use of features helps, is there any othe= r guidance that needs to be given?

We could set the =E2=80=9Cstatus=E2=80=9D to = =E2=80=9Cdeprecated=E2=80=9D.=C2=A0 That said, it's one thing to say th= at a protocol is deprecated and another to say that the configuration for a= still somewhat widely-used=C2=A0deprecate= d-protocol is deprecated=E2=80=A6thoughts?

=

I agree that we need to allow the configuration= of older TLS versions in the YANG module.=C2=A0

I found this comment from Ben to be useful -=C2=A0htt= ps://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9PymiovieA/=C2=A0 . I ended up putting MD5 and SHA-1 support under a feature 'de= precated'. In this case, I think just adding some text in the descripti= on around the existing features for older TLS could also do the job.=C2=A0= =C2=A0

D= hruv

--0000000000003a814705c061b898-- From nobody Tue Apr 20 05:40:03 2021 Return-Path: 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 A486C3A20E7; Tue, 20 Apr 2021 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 K8TOdbj1sLtZ; Tue, 20 Apr 2021 05:39:57 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60060.outbound.protection.outlook.com [40.107.6.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABC83A2286; Tue, 20 Apr 2021 05:39:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KN62Q81yvurp3nT+BMpf8opClViokLxCP/ZB5Utjqbow4VCWWvDirupfXVSjPEk5kkQFMUG+Ew+VVyWd9jddKIdR/Tn4fShe67oHsdKLFL2NpDQZ5WgZgvdq6ODGOdY1SGsH9mL8ehgJ2PXnXAbzREAmVYkX3yoBanFG6zF4aKTOyn1D5ar0syaSLRBcGsJ3YHO8+uGJOBfJfDQ3FZKquuHl1fKY8kz2s/xsB0+7TvVEDlbGHSya1ZEuW4nGyemDpDgpee5UHwg4hAKRt430gVtTvh1ErcneBsLpuKMDrrI/qwaaAmoUxMtRLrei+g4Iu4HdTUcHAqO41q7aQ7kDBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ykAiXmfPXz2j1iHAPuKhN4NzGHQvl6NOdLwzgJI+Lo=; b=EzwaTly6bM4bhHk8Gy1FNhs/PqcA0/pT4kyymKRcHuQQx4hcipTQkcKL+kF6ajrvsuhPbkSumjaqya6JCZaXVuyb7dp3M542lLdtnqquU1zHv3lI4ZQ3EpCFQ6kuUuBBPAI5pseHhVPjoHn3zb7kQhZP0Rdhvgl+znmhsHklUAeG9wCcJY++sv2AEomDhpYdsfJlRjm07odU3BYaQ6GyewfXHQK6PAumfHh7l9UeqrLn9/eHAVJWhAhqwgJRhMEnGPSAl4qBfa1uQB1RntgKsBkGbnX8s5N/T9MyY6z1jgmmiIuw9YoW77B5Uej2iG9J3hQsOpZvBpOdTaOWZfC5QQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ykAiXmfPXz2j1iHAPuKhN4NzGHQvl6NOdLwzgJI+Lo=; b=mcfifW5DA5M70KHRSASxEJBUFP/10mcKrRbQQ1/8/RonT0bjhPTxyCeXR9aWe6kG2JxwFIG+o9XABENgrHnwgdbOVaA1gJdYjDjD+tza/6bfnDssQ1QHDUyE785vrLlGJVA8C5D32bApbXObf0v1PwzdHVSMKTyQawvk+oCBQfw= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0692.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:195::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Tue, 20 Apr 2021 12:39:15 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.024; Tue, 20 Apr 2021 12:39:15 +0000 Date: Tue, 20 Apr 2021 14:39:13 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: "netconf@ietf.org" , YANG Doctors Message-ID: <20210420123913.74ejllmgty5z2w6k@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" , YANG Doctors References: <161045360252.14510.16755799701987783827@ietfa.amsl.com> <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com> <20210416115004.fqhitq6jofc6vjih@anna.jacobs.jacobs-university.de> <01000178ec7bfedf-5b8a2940-2fdd-42f5-ae43-27277d991769-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01000178ec7bfedf-5b8a2940-2fdd-42f5-ae43-27277d991769-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR3P189CA0087.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:b4::32) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P189CA0087.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:b4::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Tue, 20 Apr 2021 12:39:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ef132f12-a60b-4371-caba-08d903f94ea0 X-MS-TrafficTypeDiagnostic: AM0P190MB0692: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: x5I3o6wO1qxTGBPEm9N+wt07sPn5zvRS5x8+Fzo4DHxqOBrZBBU6gxa/odDFHLbpseeBEW2vmUsIRBDA41nqjmcCnAH4WLN+wvGArxdikF+venXNtOqUbc8pllv82IDQPbXpRgGewJB6AdCRmmZuhNxmbnvYy9MpsThsLRRd0a04ySWRtKAmj50jHCeit7DEeySvrEcSg1kv5Tx2xfVzF9CIaPpmd5XF5C1FzYfvlW7eKV3cJCRfQZ/kPhao3VltbEgoSZDjAaFN+FSlpvCd+RHZgWz3oeoVOr598F/J7X6m8gg913wnBhlBT/U9fxsUa+ko/sxeNMQex0iWLsTQL62KOAcTrdovCsc/rlbkT5+5ImRjJaplVi+JKdR28FL73C2wHGAJJmDlxMuxm/neY3VwPKV6XJ+wtYAJx2rNHSse1D4OpsPleugb3IXW3NmDeNZ7TEiVHnzkcGPHU3tt4zdva24gvnZRgKtm+v/BLtep/W2KgcVV1BIm08urW0Zuv++DHgTiq1kX4RVBzu/+RujqXyZvBCDFuRmdWMZVXAdZC4p80thxdKkNsxvtg/6xC6F1fTC3hjJGyeUsjb2JbeLrOzAG5eYsMXJfyMGfF2TczBMYNNyWM6RoAUFDx+Z5a0LDu14bx+YU+PyLBcLfIblCC65JDVVwTz1fDxSkYwPxzQOWpaDl5cIp1hgp+LFzg4+/WewSXQKo5U6/qXUv/OOzZbC7WqcGKCskmwYR0bqMimJ6L3e9WIiQj1bhnOOl X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(498600001)(16526019)(26005)(52116002)(6486002)(38350700002)(6496006)(5660300002)(66476007)(2906002)(186003)(86362001)(956004)(4326008)(83380400001)(38100700002)(54906003)(8936002)(66556008)(66946007)(8676002)(3450700001)(1076003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?L3pyNlVub05SWnBDQkZqSWlackRyeTdOTkp1MU5MelQ3U2hhOTRmTGlidDRF?= =?utf-8?B?TXlmMEdyczR5ZW1FdUlRUmxGVnQxaXRBOC9oMDFhdXNTYzQ4enlZWjZTNkNI?= =?utf-8?B?L0d2UXZsOGFHQitXaUViMkMzQkNzQTRUei9HTjRHOTVpRnorMDBlOS9hN2Nw?= =?utf-8?B?aGtGbFVsb2FNVFZjUmRLVG5oeGFjQ2huNGFsTml4aS9JMUEvZkZEVzhKVnNX?= =?utf-8?B?bDFVN3ZFblpKRm4wTklxUERUcWRIZzBOMTU2RExKQ0FxS1lLOVoxR0JOcGNS?= =?utf-8?B?eEkxbDhFVzJ5anMvYXEvZjZIbGg2Yk1PNlp2czlnY0U2bklranBsRFRKSFk4?= =?utf-8?B?V3YvQ0ZYNHlZY1l6VHpQRG1Pc1VIQm93UUV3amFuSlliUnpuM3pkRGN1ODhL?= =?utf-8?B?M0UwUFBRcm5lVkFRZmMzVnRUZTk4Y2ExT01HVVBaa3A1Vy9QRDhDV2VzQk5i?= =?utf-8?B?UlpQalNBZ2RrQWR5Qm9UNG1NeHN4RHljVnNxcjJ3NlZ6ZVhqRGNqOEVFeUpP?= =?utf-8?B?NVNPb0E3dS9ManhYVHBLb2RCQ29peExBK1oxUGtSRkNjUHNybUswaVZCalVY?= =?utf-8?B?QWc5WWJ5RjVmdkNQRWhDdXZPZ1NOZlhNcUZINHVmTVNadVRvOXRSdWpYQlZI?= =?utf-8?B?cC81ci9kM2w3QzY0dDNiZ3dOYWJaa3p2Wjg2T2syQ25QSHRVSm5TNnhzY3Vk?= =?utf-8?B?eEg4TkhObk9WY2c3ZHZGbWJpRmNHWld3UjdmUG9TS01NRkxOKytIcmR5SjFH?= =?utf-8?B?YVZiZDBrVEloRWF2UG8rbXU2N09WN1d0R2JHRW1CREd2N3ZXdzhBSUM2U1hC?= =?utf-8?B?R2pGNERqRkM4Z2hIUjlETFRFNDNiY0hHa055ZTJVVEl0TGpld1VDQmM3Nmpt?= =?utf-8?B?VkhDd2FJVS93R3RUSE5DUHN6TkgrQVNLSzE1a1ZUeWlLYXdsbW4zUEZhUWpF?= =?utf-8?B?VjhFN21QdjY5b0JCdjY3YzFlZ0xvalNaY3FoTkM5YXRtc25pbjJ2NUNVRVhw?= =?utf-8?B?WVV4ZjluSHc5VHlDRGxoUmNuWTJoMzJ0dThjZDRxQTRKcTBSR05Razd6UmNm?= =?utf-8?B?M3ViSmFnSkhRMXhyR3U1dEhmd1ZDQ1BQbHl3RWZqWjlzaExwVCtIVlA4eVcz?= =?utf-8?B?NTJ3UHhHdzFpMnkwakdXRCtnVXhNc09WSmxFeXkwUWh5MTE1WVR3NjlhWGxv?= =?utf-8?B?UEVkYUVFSWgrT3ZSUkwwQjRKTlUxb3JWYzh1cFIxdlFSRXM0clR0ejIwcVpM?= =?utf-8?B?cTJxZG1XYzlheFF4MWxXZ2htejluUUcySFpKNEkxb3ZHRkNyd3ZCcDNWMllo?= =?utf-8?B?dnNpVTYySVBUMXBVekkxUkhSblYyMDUxc3lMOUU4MGhPSkhjSHJUY2wyanYr?= =?utf-8?B?OEZ6TU1zUnB4WUNTQzlPNHpYN3dWanZXeHBhWllqNmxsYkphUHN0NFpDN3d3?= =?utf-8?B?VWpMS2VqYXdTa0hKY1RwRGhodW9WZ2lSL1JJWk5VdmNoZDMzdmtxSmdSdVhx?= =?utf-8?B?bnF2RmdXQmsrT0xsTmNIZytQVjlNYmQvNzlVSmFHRjJRT3diVXBQaFlMQVMw?= =?utf-8?B?VEpINlcwVjhMRDYvOUhmZHZXRE9sL1g2UlhNdnZUekVCYU4wVjkzS01YWWxC?= =?utf-8?B?czhKQ3JyVGxIY1Z4eHliLzBmMVVYVVdyMTdmNEFoMllaMHNrN3lrSjZmSHFm?= =?utf-8?B?Y3FPUXFrQ255d2FQT1U5MkRnclJ2Nk1jR0FHR0ZvcUZsZy90dVJlbUNlWTkv?= =?utf-8?Q?G7hj9XR/GXpgwy1WjX3yZkG4znLze3dWwl6SvUP?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: ef132f12-a60b-4371-caba-08d903f94ea0 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2021 12:39:15.1970 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hPmUZ+w3ZE93HAgmR9D6+FIMSgZp2343BQM/Z0Tn+ps+5AxypqUUUV8AivUSGhD17WedzENEJXLiXFetOWOtnjapcD3hGnk+nRxtVcBH18I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0692 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 12:40:02 -0000 On Mon, Apr 19, 2021 at 11:34:12PM +0000, Kent Watsen wrote: > > Hi Juergen, > > Whittling out things resolved... > > K. > > > > >> - Does it make sense to have a new notation like > >>> > >>> | The diagram above uses syntax that is similar to but not > >>> | defined in [RFC8340]. > >>> > >>> or shall this simply become regular text? > >> > >> I find using tree-diagram like notation for features, identities, and typedefs helpful, especially in showing the “if-feature” constraints and hierarchical relationships between items. I recommend adding these enhancements to RFC 8340. It would be helpful if someone could whip up an I-D so these documents could reference the I-D instead of having the "The diagram above uses syntax that is similar to but not defined in [RFC8340]” language. > >> > >> That said, I also used a "rfc8340-like" diagram to list all the groupings in a module. It seems like the consistent thing to do, but I can’t imagine the RFC 8340 being updated to support that output, so I replaced that diagram, with a normal "xml2rfc" list, in the entire suite of drafts. > > > > I am sorry, I should have been clearer. My comment did not concern the > > diagrams but the mere fact that you have > > > > | The diagram above uses syntax that is similar to but not > > | defined in [RFC8340]. > > > > instead of simply > > > > The diagram above uses syntax that is similar to but not > > defined in [RFC8340]. > > > > and this is really an editorial nit if at all. The diagram itself I > > like, it would be nice to have them in RFC 8340bis. > > Ah, now I understand, you mean to remove the XML2RFC v3 “aside”? I agree that it renders poorly in plain-text, but it renders inside a pretty-box for HTML and PDF. Thoughts? Ah, its called an "aside". I am still reading plain-text but the question likely is what belongs into an aside box and what into text. For me, there is no reason to put this sentence into an 'aside' box - whatever the purpose of such a box is. Its just a regular sentence for me. > Yes, the diagrams would be a nice addition to an 8340bis. Also, I don’t know if you noticed, but the “Data Model Overview” section I created in all these drafts is highly mechanical…something that could be mostly automated…perhaps a good student project? ;) Students tend to do something half and then disappear. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 20 05:42:44 2021 Return-Path: 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 BE8C43A2102; Tue, 20 Apr 2021 05:42:33 -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=nic.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 1SBblbJWhXwg; Tue, 20 Apr 2021 05:42:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321453A2100; Tue, 20 Apr 2021 05:42:28 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id A290E140828; Tue, 20 Apr 2021 14:42:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1618922545; bh=KrRYsB1IIF/3V7M/Wax4Z9ydVBsfZOIgKu9esFd3wkI=; h=From:To:Date; b=sw5dKYcxYlQcxlMhVFqPYEzK8HwBGndfU+baD1LTSyTIeNXhUWdpjzOEC4hzKCAHi MrBZG+ps/aEsABuRuIodeNkRQWgM/jP7IYFsitH1TQ8HMOiwGk2b/UUqomTxW9xtYS sGLO3JYIhhy/0ANynZyAzrNaeBLXT2hLX+ICfv4M= From: Ladislav Lhotka To: Kent Watsen Cc: YANG Doctors , draft-ietf-netconf-tcp-client-server.all@ietf.org, last-call@ietf.org, "netconf@ietf.org" In-Reply-To: <01000178ebd39133-87ef25f3-1047-4f02-b5fb-706e82e7c02a-000000@email.amazonses.com> References: <161796231010.8005.7390142571009530431@ietfa.amsl.com> <01000178ebd39133-87ef25f3-1047-4f02-b5fb-706e82e7c02a-000000@email.amazonses.com> Mail-Followup-To: Kent Watsen , YANG Doctors , draft-ietf-netconf-tcp-client-server.all@ietf.org, last-call@ietf.org, "netconf@ietf.org" Date: Tue, 20 Apr 2021 14:42:25 +0200 Message-ID: <87tuo1w2j2.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-tcp-client-server-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 12:42:34 -0000 Kent Watsen writes: > Hi Lada, > > Thank you for your review! > > Below are responses to your comments. > > K. > > >> Reviewer: Ladislav Lhotka >> Review result: Ready with Issues >>=20 >> The modules are well designed and nicely documented, both in the descrip= tions >> and text of the Internet-Draft. > > ;) > > >> **** Comments >>=20 >> - Sections 2.1.4, 3.1.3, 4.1.3: the sentence 'The "..." module does not = contain >> any protocol-accessible nodes.' is misleading in that the modules do def= ine >> data nodes that are intended to be protocol accessible after the corresp= onding >> grouping is used. I know this is a part of the NETCONF/YANG lingo, but a= nother >> formulation that clearly says what's going on might be preferable. > > Fair enough. How about this? > > The "ietf-tcp-..." module does not itself define > any protocol-accessible nodes. This module defines > only "grouping" statements that are used by other > modules to instantiate protocol-accessible nodes. > What about using just the last sentence? It says all. > > >> - Sections 2.2, 3.2 and 4.2: the XML snippets use document elements >> "tcp-common", "tcp-client" and "tcp-server", but these containers are not >> defined in the corresponding modules. This is confusing, my suggestion i= s to >> rewrite the examples in the JSON representation where no such top-level = node is >> necessary. > > Indeed, and my validation script even takes the special step to convert t= he groupings to containers in order for the validation to succeed. In oth= er modules, I created a =E2=80=9Cfoobar-usage.yang=E2=80=9D module to insta= ntiate the grouping statements. > > Hmmm, I was about to create the JSON, but realized that it would be easie= r to strip out the first-and0-last lines from the XML examples. I understa= nd that they're not a valid XML documents, but snippets have been used befo= re=E2=80=A6 > > FWIW, all the examples are still validated, so there=E2=80=99s otherwise = no loss in correctness. Maybe it is not necessary to validate these short fragments. In any case, a= casual reader might be confused - where do these elements come from? As a = minimum, some explanation should be added. > > > >>=20 >> - What is the purpose of "tcp-connection-grouping" if it only uses >> "tcp-common-grouping" and nothing else? Why cannot "tcp-common-grouping= =E2=80=9D be used directly? > > I added this comment: > > Whilst this grouping appears to not add any value beyond that given > by "tcp-common-grouping", it is defined so as to provide space for a > future peer module (e.g., "tcp-system-grouping" that defines addition= al > configuration nodes used to configure a TCP stack at an operating > system level. OK, so this new grouping could use equally well either "tcp-connection-grou= ping" or "tcp-common-grouping", and add more configuration nodes. Having tw= o names for the same thing is confusing. > > Makes sense? > > >> - The "local-port" parameter defined in ietf-tcp-client seems dubious fr= om the >> security viewpoint in that fixing the source port makes it easier for at= tackers >> to steal the connection (see RFC 6056). > > Interesting read. But note that the RFC regards primarily cleartext prot= ocols. An axiom in security circles is =E2=80=9Cobscurity is not security= =E2=80=9D, i.e., randomizing client ports to make off-path guessing harder = is not much of a win. I don't think this can be labelled as security by obscurity. Without crypto= graphic protection, it is basically the only available measure against traf= fic injection. In DNS, for example, source port numbers (and transaction ID= s) with insufficient entropy are considered security issues. > > In our case, and pretty much every IETF protocol now, a secure transport = layer is used, and having a predictable 5-tuple can greatly reduce the atta= ck-surface in firewall rulebases. > > As it stands, it=E2=80=99s configuration enabled by an optional feature (= your next comment) and, besides, the wildcard values (e.g., =E2=80=9C0=E2= =80=9D) may configured, enabling [potentially-random] operating-system sele= cted values - so no harm? > > >> If the feature >> "local-binding-supported" is needed at all, I'd suggest to mention this = in >> Security Considerations. > > =E2=80=9CNeeded=E2=80=9D is an interesting take. My feeling is that the = model is > incomplete otherwise. From a Security Considerations perspective, I was thinking it might be needed for cases like NETCONF call home. Otherwi= se, it is not common to be able to configure the port for the side that per= forms active open. > I=E2=80=99d like to put something like: > > =E2=80=9CImplementations are RECOMMENDED to implement the 'local-bindi= ng-supported=E2=80=99 feature for cryptographically-secure protocols so as = to reduce to attack surface presented by firewalls.=E2=80=9D I don't understand what firewalls have to do with this issue. On the other = hand, I would also mention the reason why this is RECOMMENDED, and cite RFC= 6056. > > Is that what you had in mind? If nothing else, having such a statement = in the draft would certainly catch the eye of the SecDir reviewer. Thought= s? Of course, a SecDir review would be more authoritative here. Cheers, Lada > > >> - The module ietf-tcp-client uses the placeholder "RFC AAAA", which is n= ot >> defined in the Editorial Note. > > Fixed. > > > >> **** Nits >>=20 >> - RFC 7950 is cited repeatedly (6 times) in a general context, e.g. when= ever >> YANG 1.1 is mentioned. It should suffice to use the citation at the first >> appearance. > > All but one citation removed. > > > >> - sec. 1.3: s/in compliant/is compliant/ > > Fixed (in all the drafts!) > > >> - in 3 places: s/illustatrating/illustrating/ > > Fixed (in all the drafts!) > > > Thanks again! > > K. > > --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 20 05:44:26 2021 Return-Path: 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 5D4393A2103; Tue, 20 Apr 2021 05:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 aWWOWiutoc9w; Tue, 20 Apr 2021 05:44:19 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40040.outbound.protection.outlook.com [40.107.4.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453EC3A210B; Tue, 20 Apr 2021 05:44:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l1o4dF41dzxVXxg+Pz0KpTj18C1M/v/ecm5kik8ItqNqGwAmudExEa5hIglWBWjpJ1lk7005RaYXpcPex2Fypu9vdLnMA87GPN0BEH3y3DIbgzg7EgKOaTl8D4MmbR92sl6cG5FF2OTXdTzzDZoX1l5Hk3uvaiv5kc8yEfl71Foh09Z5eDpuibdNgcWolFuQBuawi28k5NWtKwQh7nGfq0y3boxXQGsCC//t7usO+iajEFwlio9ChgRVOQ/lz/5g7jI5vJ6xPcs6XlV6m1ed8T/jV2OPYHnGpZYtU0H0GAt3xfw3UvtD1OiA+ZbBFb1Gvy9DI1uXn8Igfacb1nCvrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h4gCZdweBSoXMPKwkUxU68JEtZk6YQy1w5BTRNrT+tY=; b=WcaB/6a02bhWItfW7mb9Ayz3VJh3/k56MNlG/bG1wA96b/sVXEWoyUKmSCKnd2cBVISn/ZkOOt+vyELNXFHowgqFyrQeTeSJqn2CCup8IrvtO1S6tCXUgFZC/B2UBNg7wLVQ4dNbdr+RyNZNZdSdS4+Xeg+GensJ5cFv5LEakLqOkmO2bwVJcu94fODGr0/EyrsM1+puAZzPeof1lrQTLZto3GVlxpaXfuilqvc00SICAOYLG2A/KL9d6GIe2wsV8OUGici3jJImea+XS4HzDZUchyora8ROsyA9pY0OZpLqde4S4aIkKAdtsbzuGImbq5ShbwJH8SCwo9aBqbDzGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h4gCZdweBSoXMPKwkUxU68JEtZk6YQy1w5BTRNrT+tY=; b=djm5X3bQxMh443o5SUa4p8kXdS0GPRW6KU87H8owkZHXFzQvBuIQeclklxjhhwdxz0tJvNR2+rDx6vSvc2kU5y4xefS+QC4rco7XckstvOIUaugwkHw/lJVoLr5fRqZSHVSPqk45oTRKUU4+LFUJrSBi9cwq/qpWp9OtN2dQ3wo= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0017.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:60::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Tue, 20 Apr 2021 12:44:16 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.024; Tue, 20 Apr 2021 12:44:16 +0000 Date: Tue, 20 Apr 2021 14:44:15 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: YANG Doctors , "netconf@ietf.org" Message-ID: <20210420124415.jjwl6nlh72obeurd@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , YANG Doctors , "netconf@ietf.org" References: <161064362767.26403.10249622617283363882@ietfa.amsl.com> <010001778e68398d-c2bff7b8-4c4e-4f30-a962-1ce39e2ece13-000000@email.amazonses.com> <20210416123749.246d6irnd3oso3x4@anna.jacobs.jacobs-university.de> <01000178ece4d8fd-09010867-cbff-486e-b598-3653e944b833-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01000178ece4d8fd-09010867-cbff-486e-b598-3653e944b833-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR3P193CA0042.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::17) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P193CA0042.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18 via Frontend Transport; Tue, 20 Apr 2021 12:44:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a3068302-e907-4aa8-c17b-08d903fa020c X-MS-TrafficTypeDiagnostic: AM4P190MB0017: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3631; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jEMebPVHdG7mEuXlXZ3rIbzABIJjBydWc/lQJm7fB1Wb51RdYh+boRnee0Hq+0ihSzphdlL2887gHq4xgXtSHcYbykc93am1TpgIhxejhX1/nWTz2yhHW2s4aLYYNvCKHZ1b0UvCX9kAZuUVpLVkvB69HuKRbbeW5eIPmtlSmeLgTMhVuOh0OFygoS/0XG2MfT6Vsq1Y8YyUDUAR1CrP5GBcNIZh1L4RZiTZ9oPgKB7mf2D3R1ZDFrkp3XSe2F1035b/rta3U38jR5BenLdGHQ1RQTTFY0O+R7Ku5fnuZ7oL27tpHXBxD2Xqlv5dYtW21LjcJX/WYsHwXIds330XZ7LFKbfmkjhY924sCxviez6TPJg/rkUcocEn/ltzGuDnePIYbzmJuUWUAMdWT16mHujXVtCOBKXfLtt/khCALuZF96SoAPMT4uBzkMVfCFr7Iq8b6dNqhNoPo9+9oZOhHOD+MBivr6xM86ut77lDwu8g1KYm4c4aXLeTjdElWVxc1NTdzubNt+W2xTaxj3Ab2MQwqNhd37u7lA0RSel6JtwjNdpz2HnqdzfAXfQdFkIANJQwf7vJ8/QdygVe9dB6znspi26SpuObi/fGSTJrpboWob9PqL98t0VeK0rhZrB9BaZaqzKeGQHyv1urW6HEXMXKCo9WBb0QKSBIwrsckufrDwRD0Emq31Bnz1vWfrqFb/CbOBv6oWIeqnuR03AmrTT4iWF1+WOcaaA6O7nvuYJpI54ikfW4swL1n1tmV2cF X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(26005)(54906003)(1076003)(956004)(4744005)(86362001)(66476007)(6496006)(16526019)(5660300002)(498600001)(186003)(4326008)(8676002)(8936002)(52116002)(66556008)(66946007)(38350700002)(6486002)(2906002)(3450700001)(38100700002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?eWxJZ0VkZDVvSGFxVHZ6ZHRmNHIzMGZuNGJUdnpEK3BNeXBZZzBHcjg1K2xu?= =?utf-8?B?NEx5Um5oT2JnNUxjQmlaS1hhbktKWmd0aFJsZW94M1UwanYvTzNnMnhvVk9n?= =?utf-8?B?em5pbHN5UEQrRGpSWHd2VEJGZHU5UTUyaGhMdWFrNHJUdVFkVzZlcFMwTEo0?= =?utf-8?B?cUJlMVhSNXhQTVlJVEVHaEl3TjJQQ3hXc1U3SVRjblNDYlZCL3liTU5tenE3?= =?utf-8?B?NXVWelYyNnVkbjRzVS9nODNadlk4QXplaUVaaGo0YVJpSllUTDhKVFBVK2t3?= =?utf-8?B?SmtQdmJKMm1PTnQ3dm5NYXZySG1LdUt2amR5c2tDVHFwQ3Z3Y01heTVSd2sz?= =?utf-8?B?WFpScE5hVStiNkpQclo4SFNGakxSVlZ0RUFhNTZqS2lxaEFuSWtvd3ZwOVp4?= =?utf-8?B?SEdCUGlqWWd6SjZBWjg0QjRQdWoxYUVmU1RjeXUrNkIraXMyUDRpaklUNDdK?= =?utf-8?B?ZURLZnpNejNESkhuTFVRZitJRmlrcVVBdEprc3VWcmRVdXk1WWR4eHJpZGJv?= =?utf-8?B?KzJISmpHbVVDeDBneHNjQXEwcUlzY1Z6b29hYW8yK0F2M1ZZSDdISFZYcER2?= =?utf-8?B?SGNsSHI5RGtsbnFidHpjdFdQSUtTSkhSbUNBV0NUNVc5anlwTnNwUmVOUGFZ?= =?utf-8?B?YmZrMk45UUxIdzlKeUVQTTZmMG9ZNkthUld1RXJqc1NKZ2tIbUVVTWppRmRl?= =?utf-8?B?L05TTG1SNjN0dHNNbm5MSDdtZmIvYkNTMTIrakQ2RUZGV2lKUVRLVkJTaUlp?= =?utf-8?B?L1J0V3dLQlRKYnk2VTZRTHo3YjVQUVJVVUhTclczbGlma2pia2RYVWxGRG9V?= =?utf-8?B?aUppUU15elo4MjNwVGN6U1kranlVZGdOSkFzMmJiK0srakxYbXB3WVgxRGNt?= =?utf-8?B?VnlUVWZzWEdiUzhZQWJYSG9ZcGNJckhrYlhTY0RXNk80RTRscE1uSFU1MkUy?= =?utf-8?B?VGxjdHV1M1ZNRWtRV1RIWDU3YnhNYnZkbklqTGVpdzNqUmcrRHBlcTliZnpF?= =?utf-8?B?UVRaMitHOWtwNkl5ZW9xWlY0TGhKb05ZWUNuRVBjR20xMkp6azFCVWk3S2VV?= =?utf-8?B?S2hBTGphR0tIdVpGWjJLcEQ1ZHZpc2JNMXNuWVdQcjVLTk82K09Gb2JkWkl3?= =?utf-8?B?Q2N2eWQ4UFlzZzg1M3gwNzNWQXFFSk5mdUN1SnQ5S2Fod0ZVaFdQb0trUkdk?= =?utf-8?B?NEs5K1JQOE1iN2NrOEVHdTdmR2NoQXdmenlZdDFyaHZ6Ullqdk9rQlREcWZo?= =?utf-8?B?UUdqS1VteUxvd0Z1dHpuNUdqNjkvU045TmJ5b3F2VDRMZXBtalhWaGNkL3R2?= =?utf-8?B?L3l4UlM2RGFOK2xWdWltNDhRclRNWEdxTTRuRzQxM3FKN3paR2QrLzVJTTdL?= =?utf-8?B?OHpKQkhLeHZUWGo5cFovdzFGSWQ2dUttR0xxVHZPc055bmlMTERTY0JyZUVz?= =?utf-8?B?VFdzNXoxNFYvS3VyYk1UVFR4NUJJc1B5MmQ2VkdvL1U0VDNOa2ZFVHpQVENG?= =?utf-8?B?TnN4b2VzYXk5ZURZeHdhNm1RMHBXMXlHYjlXMFlWZk54TmYxMlBhVG41MjRR?= =?utf-8?B?SDNxWWtwMHNCei8vRlJqeW03Zks0d1pqb0xZMnpQZWhxbVRrSVYzMysyMkdw?= =?utf-8?B?bktPQUJIVTlVUExWdWJ5dkdzQ1dGcEJEOTlYT0hvTlA1WTBVMktUT3IwZU8y?= =?utf-8?B?aGZ4ejF3OUZ1ZGhSOStOQ25JRFV1U2xGZitKT0F2MXdjUDFNNGxjQWd5WCtV?= =?utf-8?Q?mVTlWg/kwWn/ZlY5VIPrBqfj3sVd5NPodRqgxxp?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: a3068302-e907-4aa8-c17b-08d903fa020c X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2021 12:44:16.2157 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: kRHTG4Y/j7vh7xrSk1oTBfabTMgIF6B7DOrqIB+rGq+tyiw/QqGV6r3y7B7JP+ffD8Djgrt7Lajc/1Tq9Ph3GrY8DY2vtVilSgFhyVpaURU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0017 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-keystore-20 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 12:44:24 -0000 On Tue, Apr 20, 2021 at 01:28:44AM +0000, Kent Watsen wrote: > > It took me while to determine what text got clipped above which you this is better. Let me clarify, you think that it would be better to both: > > OLD; keystore-supported > NEW: central-keystore-supported > > *and* > > OLD: … the keystore, when this module is implemented > NEW: … the central keystore, when this module is implemented > > Correct? Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 20 05:59:06 2021 Return-Path: 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 53DC03A21B0; Tue, 20 Apr 2021 05:59:00 -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=nic.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 cuRCDb3GNFeo; Tue, 20 Apr 2021 05:58:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AAC3A21AD; Tue, 20 Apr 2021 05:58:54 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 87DA1140828; Tue, 20 Apr 2021 14:58:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1618923530; bh=NLs+q6+CIaaAb6xyTSbXvAY8eFZaCn0M/4/aEuT+a3o=; h=From:To:Date; b=WFbeYkQvPyKnc2ZfczW+qrPrH9gkNDzQuswu1e6jIA/W8x/1O53t7VnZ4ZmfnNmkO JVOUJ4yA5zWh4jeaVIqDn5C3hy2N4l/f0U4Iv9iiYt4spdl3drQH7x3bv9q9bXuSYX 9EO6d2O21mOkpjJfzhSqKnz+z4bWH205vyWPFpP0= From: Ladislav Lhotka To: Kent Watsen Cc: YANG Doctors , last-call@ietf.org, "netconf@ietf.org" , draft-ietf-netconf-http-client-server.all@ietf.org In-Reply-To: <01000178ec3aebdf-1c5e3f62-5432-4d07-80d4-85480626a545-000000@email.amazonses.com> References: <161821556350.10432.14910369341748800490@ietfa.amsl.com> <01000178ec3aebdf-1c5e3f62-5432-4d07-80d4-85480626a545-000000@email.amazonses.com> Mail-Followup-To: Kent Watsen , YANG Doctors , last-call@ietf.org, "netconf@ietf.org" , draft-ietf-netconf-http-client-server.all@ietf.org Date: Tue, 20 Apr 2021 14:58:50 +0200 Message-ID: <87r1j5w1rp.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-http-client-server-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 12:59:01 -0000 Kent Watsen writes: > Hi Lada, > > Thank you for your review! > > Below are responses to your comments. > > K. > >> On Apr 12, 2021, at 4:19 AM, Ladislav Lhotka via Datatracker wrote: >>=20 >> Reviewer: Ladislav Lhotka >> Review result: Ready with Nits >>=20 >> The document defines two YANG modules - ietf-http-client and ietf-http-s= erver - >> that belong to a relatively complex set of modules. The modules are well >> designed and nicely documented, both in the descriptions and document te= xt. > > :) > > >> **** Comments >>=20 >> - Sections 2.1.3 and 3.1.3: the sentence 'The "..." module does not cont= ain any >> protocol-accessible nodes.' is misleading in that the modules do define = data >> nodes that are intended to be protocol accessible after the corresponding >> grouping is used. I know this is a part of the NETCONF/YANG lingo, but a= nother >> formulation that clearly says what's going on might be preferable. > > I fixed this when I addressed the same comment made in the =E2=80=9Ctcp-c= lient-server=E2=80=9D draft. OK > > > >> - Sections 2.2 and 3.2: the XML snippets use document elements "http-cli= ent" >> and "http-server", but these containers are not defined in the correspon= ding >> modules. This is confusing, my suggestion is to rewrite the examples in = the >> JSON representation where no such top-level node is necessary. > > Same solution as for the =E2=80=9Ctcp-client-server=E2=80=9D draft, which= is to simply remove the first and last lines, for the non-existent =E2=80= =9Ccontainer=E2=80=9D statement. > > Update: I was going to proactively-apply the same solution to the =E2=80= =9Cssh=E2=80=9D and =E2=80=9Ctls=E2=80=9D drafts, but I couldn=E2=80=99t be= cause the top-level element defines additional prefixes. This is where you= r =E2=80=9CJSON=E2=80=9D idea could help, though, for some reason, having a= mix of XML/JSON in the suite of drafts is off-putting to me. We could con= vert all the examples to JSON, but that=E2=80=99s a fair amount of work too= =E2=80=A6 If you already have that "foobar-usage.yang" module, you could possibly tra= nslate these snippets automatically using the "jsonxsl" plugin of pyang. I also think that JSON examples are easier to parse for a human reader. > > How about adding an XML-comment indicating that the top-level element doe= sn=E2=80=99t really exist? Yes, as I wrote in the other review, some explanation might suffice. Lada > > >> - Placeholders BBBB, CCCC and EEEE are defined in Editorial Note but nev= er used > > Fixed. > > >> **** Nits >>=20 >> - RFC 7950 is cited repeatedly (4 times) in a general context, e.g. when= ever >> YANG 1.1 is mentioned. It should suffice to use the citation at the first >> appearance. > > Fixed. Also in the =E2=80=9Cssh=E2=80=9D and =E2=80=9Ctls=E2=80=9D draft= s. > > > K. > --=20 Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 20 17:57:47 2021 Return-Path: <01000178f1eec59c-13739cd6-210d-4c68-9270-a921ddd9404e-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 43DA43A0DF6 for ; Tue, 20 Apr 2021 17:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 IcimByPIlMIk for ; Tue, 20 Apr 2021 17:57:42 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D32F3A0DEA for ; Tue, 20 Apr 2021 17:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618966660; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=K1ps5Qk3nXTCOfSUYGRhHDyNwvVhc9wp/2YIVXfNjpI=; b=KeB/uPFVKcMEWIAeUg5CsZRplyObh2qZun/kBYj7deNlxzNXXyuXLRlggqjqycw7 bw0KaS5EmWAqm19E+UiEBhmQgexbwlDsb6cKkfmrhi/7ycwUM0QZZlkZUPhzihJjpoV JYj3n/Vx9Yz3+tJe8+j2j6UxwqlShwhiJR5sD9A0= 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 In-Reply-To: <1104-607e6b00-3-2fba9200@222555441> Date: Wed, 21 Apr 2021 00:57:40 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000178f1eec59c-13739cd6-210d-4c68-9270-a921ddd9404e-000000@email.amazonses.com> References: <1104-607e6b00-3-2fba9200@222555441> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.21-54.240.48.92 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 00:57:46 -0000 Hiya Michal, Please see below=E2=80=A6 K. For this response: > I am using only the "keyboard-interactive" method and only as a user, = so I do not have in-depth knowledge. However, it seems fine and should = be now configurable, thanks! Like I said, I cannot say much about the = "gssapi" methods, never used them. But they also seems fine to me. And this response: > We are not using them (yet) as the last draft we implemented was still = missing some features. Looking at it now, it seems okay. My understanding that you =E2=80=9Cthink" these updates are okay, which = is greatly appreciated (your considerations, that is). It would be = perfect if you could actually try them out before this work gets = published... FWIW, my guess is that there=E2=80=99s at least a month until the = netconf-client-server and restconf-client-server drafts complete their = WGLCs, assuming they get kicked off in the next week or two as expected, = and then we will quickly reach the point where it will be too late for = anymore easy =E2=80=9Cdo-overs=E2=80=9D. > An improvement I can think of is to put all the authentication methods = in "users/user" in a mandatory choice. The authentication methods would = be one case, while something like "global-config" (empty leaf, for = example) would be the other. That should allow for maximum versatility = when one could configure the 'global authentication methods', enable the = "client-auth-config-supported" feature to configure the recognized = users, but use the global authentication methods settings for some/all = the users (not having to configure each one separately). Because that = will probably be our use-case. Could you provide a tree diagram snippet that illustrates this? = Regarding your last sentence, I imagine that that might be many folks = use-case. That is, the actual user-auth might be somewhere else (e.g., = PAM, LDAP, etc.); it might be rare thing that folks would want to config = users inside the =E2=80=9Cssh-server-grouping=E2=80=9D. The following regards the "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs=E2=80=9D if-feature statement: >> But I wasn=E2=80=99t trying to fix your original issue. As = mentioned, there is a YANG-next issue and the best that consuming = modules can do is to 1) enable all the features defined in these modules = and 2) augment-in =E2=80=9Cuse=E2=80=9D-specific feature statements = where the groupings are used. >=20 > Okay, I suppose this can be done although it seems to me like a minor = deviation (the augment solution). What is the reason for not having the = module this way out-of-the-box? It might be helpful to recall that this =E2=80=9Cif-feature=E2=80=9D = statement is in the netconf-client-server draft, and thus likely should = be discussed in another thread. That said, we=E2=80=99ve come so far = already, so why not a little more, right? ;) So, do you have a proposal mind? K. From nobody Tue Apr 20 18:11:38 2021 Return-Path: <01000178f1fb7326-30c5cb08-c218-4987-a097-718628511e5b-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 8ED573A0F46 for ; Tue, 20 Apr 2021 18:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0yKb-4pHPjnY for ; Tue, 20 Apr 2021 18:11:33 -0700 (PDT) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF753A0768 for ; Tue, 20 Apr 2021 18:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1618967491; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=n5Yade3QVueOHzWmTfL1PIr8oRFtlm2iRzWfnd8N5cM=; b=WS77cLuIs7SNnbzGuiknD5HQqGIelOVIhQwrhfBDGGwggF4Jt6m1MWqzAABO9M2G fXqzygJ0wHLL/9pB+WvxSp6NF21jS8v+r1mIlbYzNG5gPXta8mdKceGW9lTMieHU/FS QlItl4WcQPGLEkz9GquHOMT2xJ4UIWnauKovsxpU= From: Kent Watsen Message-ID: <01000178f1fb7326-30c5cb08-c218-4987-a097-718628511e5b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_99D79F34-7304-4152-ACD7-86A519D2632A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 21 Apr 2021 01:11:31 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Dhruv Dhody References: <01000178ec6ee506-50ea847c-93a5-4e6b-a99a-02e85a2e74fc-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.21-54.240.48.95 Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-tls-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 01:11:38 -0000 --Apple-Mail=_99D79F34-7304-4152-ACD7-86A519D2632A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dhruv, >> - I am wondering if anything needs to be done for the older versions = of TLS which are made historic. The use of features helps, is there any = other guidance that needs to be given? >=20 > We could set the =E2=80=9Cstatus=E2=80=9D to =E2=80=9Cdeprecated=E2=80=9D= . That said, it's one thing to say that a protocol is deprecated and = another to say that the configuration for a still somewhat widely-used = deprecated-protocol is deprecated=E2=80=A6thoughts? >=20 >=20 >=20 > I agree that we need to allow the configuration of older TLS versions = in the YANG module.=20 >=20 > I found this comment from Ben to be useful - = https://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9Pymiovie= A/ = . I ended up putting MD5 and SHA-1 support under a feature = 'deprecated=E2=80=99. Wait, you put the support under a feature called =E2=80=9Cdeprecated=E2=80= =9D or under a deprecated feature (called something else? > In this case, I think just adding some text in the description around = the existing features for older TLS could also do the job. =20 That=E2=80=99s easy enough. For each feature except 1.3, I added to the = =E2=80=9Cdescription=E2=80=9D statement: "Please note that TLS 1.? is obsoleted and thus it is NOT RECOMMENDED to enable ths feature.=E2=80=9D Is it what you had in mind? K. --Apple-Mail=_99D79F34-7304-4152-ACD7-86A519D2632A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dhruv,

- I am wondering if = anything needs to be done for the older versions of TLS which are made = historic. The use of features helps, is there any other guidance that = needs to be given?

We could set the = =E2=80=9Cstatus=E2=80=9D to =E2=80=9Cdeprecated=E2=80=9D.  That = said, it's one thing to say that a protocol is deprecated and another to = say that the configuration for a still somewhat widely-used deprecated-protocol is = deprecated=E2=80=A6thoughts?



I agree that we = need to allow the configuration of older TLS versions in the YANG = module. 

I found this = comment from Ben to be useful - https://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdk= pN9PymiovieA/  . I ended up putting MD5 and SHA-1 support under = a feature 'deprecated=E2=80=99. =

Wait,= you put the support under a feature called =E2=80=9Cdeprecated=E2=80=9D = or under a deprecated feature (called something else?



In this case, I = think just adding some text in the description around the existing = features for older TLS could also do the = job.  


That=E2=80=99s easy = enough.  For each feature except 1.3, I added to the = =E2=80=9Cdescription=E2=80=9D statement:

    "Please note that TLS 1.? is = obsoleted and thus it is NOT
     RECOMMENDED = to enable ths feature.=E2=80=9D

Is it what you had in mind?

K.



= --Apple-Mail=_99D79F34-7304-4152-ACD7-86A519D2632A-- From nobody Tue Apr 20 21:21:07 2021 Return-Path: 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 C5DDD3A0BA8 for ; Tue, 20 Apr 2021 21:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (2048-bit key) header.d=gmail.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 YW8gwi6k4gbw for ; Tue, 20 Apr 2021 21:20:59 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D073A0BA0 for ; Tue, 20 Apr 2021 21:20:59 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id q25so9427537iog.5 for ; Tue, 20 Apr 2021 21:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rs0qG0rnnScAVsDyMfAK886WvhngatCEsQoujowQ81o=; b=PY2m4g8SndTHMsof3qzl3jYLQjugm50dF31IRYVdkNbjB7LrdGGoHumFCT5cpIb5IH 1GAG4D0MNEP7zjvFFObE4GQrteOJUdgXqLtgQSS3Zf2LbWy96/N6/KtXloUR8h2TTtaw rEgzi2/m8UPLMfdTqvpOeHCV4EN1/pVUgdENpfWVYYkcroMrMUB5prV35kabUcJ30PV2 RCnWeVn1X5dZH66hYkQU4AFU98OnQ76m2cU5TIFP8B3Wbmbw5npJ2tb1ryDvC7YR5pYh 9bPEXtf/JLjgERtHg8DfsRm8lZdroDOeDxOCi6j6RWpTRsSLgnIBIPU/gq9R/SZUqiEn WDCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rs0qG0rnnScAVsDyMfAK886WvhngatCEsQoujowQ81o=; b=V8m/ckcD2BhJSL+1engpQFXPn8w56CCfpSPDOsGdyUsvyQHwopc9YYZCAor8Sg16dH D1Pd6ml0CJHYW/0CMluAywW4Xa1HSlv29MQl+jvhv2Va0RQjLDsmmNvwayaioKUjvGrl yW6EyXby54UpMV2qiy10z/dMlBUA6YWxECyZsbww3IhFZltSS/kw+suk32Hocpg9ba1X 4HY5NOkrW38OV0JA7wq32LyTJED7t7de7wCo8vMFdV1oIBucZPShp9NZe8rkAdzwwXZI +lRUBDaA6Ce9wj6cSgMn6A6mib/o//zIIywEnr4IiAIrq+epcEHE3N0Z0W2gSMDwFSxb TZvA== X-Gm-Message-State: AOAM533UEQ8YPuurkAuLcSdDUvw3QD6IVL3YRNG8a0W6wlTyKXmliYcx xsH9gN1B12/EMYaNtNl8QbG98wlVjKCcZ9kw6EM= X-Google-Smtp-Source: ABdhPJzkKZ2Kc+qZyZoS9zdXyREouk+GRYprXKDuETZVTHPvWgH+ffifDKkH5JWQcKZ6J5QownuWuoIL1c+aEsktg6I= X-Received: by 2002:a6b:4908:: with SMTP id u8mr21998610iob.143.1618978858013; Tue, 20 Apr 2021 21:20:58 -0700 (PDT) MIME-Version: 1.0 References: <01000178ec6ee506-50ea847c-93a5-4e6b-a99a-02e85a2e74fc-000000@email.amazonses.com> <01000178f1fb7326-30c5cb08-c218-4987-a097-718628511e5b-000000@email.amazonses.com> In-Reply-To: <01000178f1fb7326-30c5cb08-c218-4987-a097-718628511e5b-000000@email.amazonses.com> From: Dhruv Dhody Date: Wed, 21 Apr 2021 09:50:19 +0530 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bb1b6f05c073e304" Archived-At: Subject: Re: [netconf] WGLC on draft-ietf-netconf-tls-client-server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 04:21:05 -0000 --000000000000bb1b6f05c073e304 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, On Wed, Apr 21, 2021 at 6:41 AM Kent Watsen wrote: > Hi Dhruv, > > - I am wondering if anything needs to be done for the older versions of >> TLS which are made historic. The use of features helps, is there any oth= er >> guidance that needs to be given? >> >> >> We could set the =E2=80=9Cstatus=E2=80=9D to =E2=80=9Cdeprecated=E2=80= =9D. That said, it's one thing to >> say that a protocol is deprecated and another to say that the configurat= ion >> for a still somewhat widely-used deprecated-protocol is >> deprecated=E2=80=A6thoughts? >> >> >> > I agree that we need to allow the configuration of older TLS versions in > the YANG module. > > I found this comment from Ben to be useful - > https://mailarchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9Pymiovi= eA/ > . I ended up putting MD5 and SHA-1 support under a feature 'deprecated=E2= =80=99. > > > Wait, you put the support under a feature called =E2=80=9Cdeprecated=E2= =80=9D or under a > deprecated feature (called something else? > > The former. Maybe I can use a different name to avoid confusion. > > > In this case, I think just adding some text in the description around the > existing features for older TLS could also do the job. > > > > That=E2=80=99s easy enough. For each feature except 1.3, I added to the > =E2=80=9Cdescription=E2=80=9D statement: > > "Please note that TLS 1.? is obsoleted and thus it is NOT > RECOMMENDED to enable ths feature.=E2=80=9D > > Is it what you had in mind? > > Yes! Thanks! Dhruv > K. > > > > --000000000000bb1b6f05c073e304 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kent,=C2= =A0

On Wed, Apr 21, 2021 at 6:41 AM Kent Watsen <kent+ietf@watsen.net> wrote:
Hi Dhruv,

<= div>- I am wondering if anything needs to be done for the older ver= sions of TLS which are made historic. The use of features helps, is there a= ny other guidance that needs to be given?

We could set the =E2=80=9Cstatus=E2=80=9D to =E2=80= =9Cdeprecated=E2=80=9D.=C2=A0 That said, it's one thing to say that a p= rotocol is deprecated and another to say that the configuration for a still= somewhat widely-used=C2=A0deprecated-protocol is deprecated= =E2=80=A6thoughts?



I agree that we need to all= ow the configuration of older TLS versions in the YANG module.=C2=A0
<= div style=3D"font-family:"trebuchet ms",sans-serif;font-size:smal= l;color:rgb(7,55,99)">
I found this comment= from Ben to be useful -=C2=A0https://maila= rchive.ietf.org/arch/msg/last-call/oVO7XyHyTtX4bdkpN9PymiovieA/=C2=A0 .= I ended up putting MD5 and SHA-1 support under a feature 'deprecated= =E2=80=99.

Wait, you put the support under a feature called = =E2=80=9Cdeprecated=E2=80=9D or under a deprecated feature (called somethin= g else?

=

The former. Maybe I can use a different name to avoi= d confusion.

=C2=A0


In this case, I think just adding some text in the descript= ion around the existing features for older TLS could also do the job.=C2=A0= =C2=A0


Th= at=E2=80=99s easy enough.=C2=A0 For each feature except 1.3, I added to the= =E2=80=9Cdescription=E2=80=9D statement:

= =C2=A0 =C2=A0 "Please note that=C2=A0TLS 1.? is obsoleted and thus it = is NOT
=C2=A0 =C2=A0 =C2=A0RECOMMENDED to=C2=A0enable ths feature= .=E2=80=9D

Is it what you had in mind?


Yes!=C2=A0

Thanks!=C2=A0
Dhruv

= =C2=A0
K.


--000000000000bb1b6f05c073e304-- From nobody Tue Apr 20 23:35:04 2021 Return-Path: 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 862C63A155B for ; Tue, 20 Apr 2021 23:35:03 -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 f-I6hEhqDCFc for ; Tue, 20 Apr 2021 23:34:58 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee: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 8FB2C3A1558 for ; Tue, 20 Apr 2021 23:34:58 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 335D060086; Wed, 21 Apr 2021 08:34:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1618986894; bh=X7XfihYnR7wSHAAeKlukSN9F+TKZkUyxB3TWJVGdYKQ=; h=From:In-Reply-To:Date:Cc:To:Subject; b=A1TeztKS+iZ+bZYUzixnj+PHNpIQ6rBz3xpu52Rr9T+B3alckCyBUTek9J3isAJdm umQ8aRqgkvzN8fFOvrhS/g/0aIJtgIQ/doYvpdzGx9Q+aqZTnvu03/fIxfcsTNdRnp mARrf4ADeSOd2KP1muvURWt8cvVfRQIf1nXQLq94= From: =?utf-8?q?Michal_Va=C5=A1ko?= Content-Type: multipart/mixed; boundary="----=_=-_OpenGroupware_org_NGMime-18607-1618986894.170225-2------" In-Reply-To: <01000178f1eec59c-13739cd6-210d-4c68-9270-a921ddd9404e-000000@email.amazonses.com> X-Forward: 84.42.188.124 Date: Wed, 21 Apr 2021 08:34:54 +0200 Cc: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <48af-607fc780-d-53523d80@24178214> User-Agent: SOGoMail 5.1.0 Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 06:35:04 -0000 ------=_=-_OpenGroupware_org_NGMime-18607-1618986894.170225-2------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 4306 Hi Kent, > For this response: > > > I am using only the "keyboard-interactive" method and only as a us= er, so I do not have in-depth knowledge. However, it seems fine and sho= uld be now configurable, thanks! Like I said, I cannot say much about t= he "gssapi" methods, never used them. But they also seems fine to me. > > And this response: > > > We are not using them (yet) as the last draft we implemented was st= ill missing some features. Looking at it now, it seems okay. > > My understanding that you =E2=80=9Cthink" these updates are okay, whi= ch is greatly appreciated (your considerations, that is). It would be= perfect if you could actually try them out before this work gets publi= shed... Yes, that is exactly what I meant. Unfortunately, I am terribly busy an= d I am just not able to implement all these modules. Even if they got p= ublished today, I think it would take us at least several months till w= e are able to use them. > FWIW, my guess is that there=E2=80=99s at least a month until the net= conf-client-server and restconf-client-server drafts complete their WGL= Cs, assuming they get kicked off in the next week or two as expected, a= nd then we will quickly reach the point where it will be too late for a= nymore easy =E2=80=9Cdo-overs=E2=80=9D. > > > > An improvement I can think of is to put all the authentication meth= ods in "users/user" in a mandatory choice. The authentication methods w= ould be one case, while something like "global-config" (empty leaf, for= example) would be the other. That should allow for maximum versatility= when one could configure the 'global authentication methods', enable t= he "client-auth-config-supported" feature to configure the recognized u= sers, but use the global authentication methods settings for some/all t= he users (not having to configure each one separately). Because that wi= ll probably be our use-case. > > Could you provide a tree diagram snippet that illustrates this? Rega= rding your last sentence, I imagine that that might be many folks use-c= ase. That is, the actual user-auth might be somewhere else (e.g., PAM,= LDAP, etc.); it might be rare thing that folks would want to config us= ers inside the =E2=80=9Cssh-server-grouping=E2=80=9D. I wanted to, but quickly learned that I did not understand this YANG pa= rt correctly. It seems every client authentication method has its own f= eature AND a leaf or container in {grouping:ssh-server-grouping}/client= -authentication/supported-authentication-methods that marks support for= the authentication method, again. Why the redundancy? Regarding the client authentication configuration, which is a separate = issue, I suppose the most generic solution would be to model it the sam= e way certificates and some other things are. Meaning, to have a separa= te container with a list of client-authentication configurations. Then,= every {grouping:ssh-server-grouping}/client-authentication/users/user = will have to reference one. That should allow support for all kinds of = scenarios, including one where there is only a single client-authentica= tion configuration and all the users reference it. > > The following regards the "tls-listen or tls-call-home or sshcmn:ssh-= x509-certs=E2=80=9D if-feature statement: > >> But I wasn=E2=80=99t trying to fix your original issue. As mentio= ned, there is a YANG-next issue and the best that consuming modules can= do is to 1) enable all the features defined in these modules and 2) au= gment-in =E2=80=9Cuse=E2=80=9D-specific feature statements where the gr= oupings are used. > > > > Okay, I suppose this can be done although it seems to me like a min= or deviation (the augment solution). What is the reason for not having = the module this way out-of-the-box? > > It might be helpful to recall that this =E2=80=9Cif-feature=E2=80=9D = statement is in the netconf-client-server draft, and thus likely should= be discussed in another thread. That said, we=E2=80=99ve come so far = already, so why not a little more, right? ;) > > So, do you have a proposal mind? Right, we are getting OT, too bad :) I have attached a diff that fixes = my concerns and I think it also makes for a more intuitive tree diagram= . Regards, Michal ------=_=-_OpenGroupware_org_NGMime-18607-1618986894.170225-2------ Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ietf-netconf-server.yang.diff" Content-Length: 628 MTUzLDE1NGQxNTIKPCAgICAgICBpZi1mZWF0dXJlCjwgICAgICAgICAiKHRscy1saXN0ZW4g b3IgdGxzLWNhbGwtaG9tZSkgYW5kIChzc2hjbW46c3NoLXg1MDktY2VydHMpIjsKMjE3YzIx NSwyMTcKPCAgICAgICAgICAgICB1c2VzIG5jczpuZXRjb25mLXNlcnZlci1ncm91cGluZzsK LS0tCj4gICAgICAgICAgICAgdXNlcyBuY3M6bmV0Y29uZi1zZXJ2ZXItZ3JvdXBpbmcgewo+ ICAgICAgICAgICAgICAgaWYtZmVhdHVyZSAic3NoY21uOnNzaC14NTA5LWNlcnRzIjsKPiAg ICAgICAgICAgICB9CjMxMmMzMTIsMzE0CjwgICAgICAgICAgICAgdXNlcyBuY3M6bmV0Y29u Zi1zZXJ2ZXItZ3JvdXBpbmc7Ci0tLQo+ICAgICAgICAgICAgIHVzZXMgbmNzOm5ldGNvbmYt c2VydmVyLWdyb3VwaW5nIHsKPiAgICAgICAgICAgICAgIGlmLWZlYXR1cmUgInNzaGNtbjpz c2gteDUwOS1jZXJ0cyI7Cj4gICAgICAgICAgICAgfQo= ------=_=-_OpenGroupware_org_NGMime-18607-1618986894.170225-2-------- From nobody Wed Apr 21 15:09:12 2021 Return-Path: <01000178f67acd58-2e857cd4-cafe-46bc-979b-712e5f777d28-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 420CA3A38D1 for ; Wed, 21 Apr 2021 15:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 zSmIOM4JxiSy for ; Wed, 21 Apr 2021 15:09:08 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF063A38CE for ; Wed, 21 Apr 2021 15:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619042946; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=gX9WX3panivtHQ5ExU+Ts8D3OjleEdevREUX0Kfx8GU=; b=FHSagFrcoh5q/djzn2UqBzxRpkmmosakoxVyJ6aweQ8olA3tKFSBxzlIVDN+eWvD qN6mv/lPaIH6uC+2zx4mfRQPk+Hqr9ASaUHJ9nMB27ImGT8j3wA3iOP4ChNRj/T/J2v i0VfgbitlKmxF/4eD+nUxkB6E2g4qLhFY8nogVxQ= From: Kent Watsen Message-ID: <01000178f67acd58-2e857cd4-cafe-46bc-979b-712e5f777d28-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A79CED06-3DBD-4966-BC63-D036F83FD8F2" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 21 Apr 2021 22:09:06 +0000 In-Reply-To: <48af-607fc780-d-53523d80@24178214> Cc: "netconf@ietf.org" To: =?utf-8?Q?Michal_Va=C5=A1ko?= References: <48af-607fc780-d-53523d80@24178214> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.21-54.240.48.110 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 22:09:10 -0000 --Apple-Mail=_A79CED06-3DBD-4966-BC63-D036F83FD8F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michal, >> My understanding that you =E2=80=9Cthink" these updates are okay, = which is greatly appreciated (your considerations, that is). It would = be perfect if you could actually try them out before this work gets = published... >=20 > Yes, that is exactly what I meant. Unfortunately, I am terribly busy = and I am just not able to implement all these modules. Even if they got = published today, I think it would take us at least several months till = we are able to use them. Noted. >>> An improvement I can think of is to put all the authentication = methods in "users/user" in a mandatory choice. The authentication = methods would be one case, while something like "global-config" (empty = leaf, for example) would be the other. That should allow for maximum = versatility when one could configure the 'global authentication = methods', enable the "client-auth-config-supported" feature to configure = the recognized users, but use the global authentication methods settings = for some/all the users (not having to configure each one separately). = Because that will probably be our use-case. >>=20 >> Could you provide a tree diagram snippet that illustrates this? = Regarding your last sentence, I imagine that that might be many folks = use-case. That is, the actual user-auth might be somewhere else (e.g., = PAM, LDAP, etc.); it might be rare thing that folks would want to config = users inside the =E2=80=9Cssh-server-grouping=E2=80=9D. >=20 > I wanted to, but quickly learned that I did not understand this YANG = part correctly. It seems every client authentication method has its own = feature AND a leaf or container in = {grouping:ssh-server-grouping}/client-authentication/supported-authenticat= ion-methods that marks support for the authentication method, again. Why = the redundancy? The = "{grouping:ssh-server-grouping}/client-authentication/supported-authentica= tion-methods=E2=80=9D container is solely for enabling the SSH-server = know which authentication methods to present to the client during the = handshake. The "{grouping:ssh-server-grouping}/client-authentication/users=E2=80=9D = container is a locally-defined list of users and credentials that can be = used to authenticate them. In theory, the "supported-authentication-methods=E2=80=9D could be = derived as the union of the methods configured for each user, but at = some point the =E2=80=9Cca-certs=E2=80=9D and =E2=80=9Cee-certs=E2=80=9D = were pulled out of that container, and so that can=E2=80=99t be the case = anymore=E2=80=A6assuming it was ever a good idea in the first place... > Regarding the client authentication configuration, which is a separate = issue, I suppose the most generic solution would be to model it the same = way certificates and some other things are. Meaning, to have a separate = container with a list of client-authentication configurations. Then, = every {grouping:ssh-server-grouping}/client-authentication/users/user = will have to reference one. That should allow support for all kinds of = scenarios, including one where there is only a single = client-authentication configuration and all the users reference it. This is where your providing a snippet of a tree diagram would be = helpful. Hopefully, with the above explanation, you're more able to do = that now=E2=80=A6? >> The following regards the "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs=E2=80=9D if-feature statement: >>>> But I wasn=E2=80=99t trying to fix your original issue. As = mentioned, there is a YANG-next issue and the best that consuming = modules can do is to 1) enable all the features defined in these modules = and 2) augment-in =E2=80=9Cuse=E2=80=9D-specific feature statements = where the groupings are used. >>>=20 >>> Okay, I suppose this can be done although it seems to me like a = minor deviation (the augment solution). What is the reason for not = having the module this way out-of-the-box? >>=20 >> It might be helpful to recall that this =E2=80=9Cif-feature=E2=80=9D = statement is in the netconf-client-server draft, and thus likely should = be discussed in another thread. That said, we=E2=80=99ve come so far = already, so why not a little more, right? ;) >>=20 >> So, do you have a proposal mind? >=20 > Right, we are getting OT, too bad :) I have attached a diff that fixes = my concerns and I think it also makes for a more intuitive tree diagram. Your diff points in a direction that looks good to me. I wish you=E2=80=99= d proposed it originally ;) How does this commit look? = https://github.com/netconf-wg/netconf-client-server/commit/29523cfb2a8561c= 578fad7aaf36107bc7ecd5afb BTW, this introduces an issue as to if =E2=80=9Cclient-identity-mappings=E2= =80=9D 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? K. --Apple-Mail=_A79CED06-3DBD-4966-BC63-D036F83FD8F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Michal,

My understanding that you =E2=80=9Cthink" these updates are = okay, which is greatly appreciated (your considerations, that is). =   It would be perfect if you could actually try them out = before this work gets published...

Yes, that is exactly what I meant. Unfortunately, I am = terribly busy and I am just not able to implement all these modules. = Even if they got published today, I think it would take us at least = several months till we are able to use them.

Noted.


An improvement I can = think of is to put all the authentication methods in "users/user" in a = mandatory choice. The authentication methods would be one case, while = something like "global-config" (empty leaf, for example) would be the = other. That should allow for maximum versatility when one could = configure the 'global authentication methods', enable the = "client-auth-config-supported" feature to configure the recognized = users, but use the global authentication methods settings for some/all = the users (not having to configure each one separately). Because that = will probably be our use-case.

Could you provide a tree diagram snippet that illustrates = this?  Regarding your last sentence, I imagine that that might be = many folks use-case.  That is, the actual user-auth might be = somewhere else (e.g., PAM, LDAP, etc.); it might be rare thing that = folks would want to config users inside the = =E2=80=9Cssh-server-grouping=E2=80=9D.

I wanted to, but quickly learned that I did not understand = this YANG part correctly. It seems every client authentication method = has its own feature AND a leaf or container in = {grouping:ssh-server-grouping}/client-authentication/supported-authenticat= ion-methods that marks support for the authentication method, again. Why = the redundancy?

The = "{grouping:ssh-server-grouping}/client-authentication/supported-authentication-methods=E2=80=9D container is = solely for enabling the SSH-server know which authentication methods to = present to the client during the handshake.

The "{grouping:ssh-server-grouping}/client-authentication/users=E2=80= =9D container is a locally-defined list of users and credentials that = can be used to authenticate them.

In theory, the = "supported-authentication-methods=E2=80=9D could be derived as the union = of the methods configured for each user, but at some point = the =E2=80=9Cca-certs=E2=80=9D and =E2=80=9Cee-certs=E2=80=9D = were pulled out of that container, and so that can=E2=80=99t be the case = anymore=E2=80=A6assuming it was ever a good idea in the first = place...


Regarding the client authentication configuration, which is = a separate issue, I suppose the most generic solution would be to model = it the same way certificates and some other things are. Meaning, to have = a separate container with a list of client-authentication = configurations. Then, every = {grouping:ssh-server-grouping}/client-authentication/users/user will = have to reference one. That should allow support for all kinds of = scenarios, including one where there is only a single = client-authentication configuration and all the users reference it.

This = is where your providing a snippet of a tree diagram would be helpful. =  Hopefully, with the above explanation, you're more able to do = that now=E2=80=A6?



The following regards = the "tls-listen or tls-call-home or sshcmn:ssh-x509-certs=E2=80=9D = if-feature statement:
But I wasn=E2=80=99t = trying to fix your original issue.  As mentioned, there is a = YANG-next issue and the best that consuming modules can do is to 1) = enable all the features defined in these modules and 2) augment-in = =E2=80=9Cuse=E2=80=9D-specific feature statements where the groupings = are used.

Okay, I suppose this = can be done although it seems to me like a minor deviation (the augment = solution). What is the reason for not having the module this way = out-of-the-box?

It might be = helpful to recall that this =E2=80=9Cif-feature=E2=80=9D statement is in = the netconf-client-server draft, and thus likely should be discussed in = another thread.  That said, we=E2=80=99ve come so far already, so = why not a little more, right?  ;)

So, = do you have a proposal mind?

Right, we are getting OT, too bad :) I have attached a diff = that fixes my concerns and I think it also makes for a more intuitive = tree diagram.

Your diff points in a direction that = looks good to me.   I wish you=E2=80=99d proposed it originally = ;)

How does = this commit look?  https://github.com/netconf-wg/netconf-client-server/commit/2952= 3cfb2a8561c578fad7aaf36107bc7ecd5afb

BTW, this introduces an issue as to if = =E2=80=9Cclient-identity-mappings=E2=80=9D 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?

K.










= --Apple-Mail=_A79CED06-3DBD-4966-BC63-D036F83FD8F2-- From nobody Wed Apr 21 16:09:05 2021 Return-Path: <01000178f6b18c8b-1b707cda-9404-4617-9301-3fe6846fcad7-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 25BA33A3A7E; Wed, 21 Apr 2021 16:09:00 -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_DNSWL_NONE=-0.0001, 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 tWMoVb7eox48; Wed, 21 Apr 2021 16:08:56 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA28C3A3A7F; Wed, 21 Apr 2021 16:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619046534; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=VsYETXGytmhYDSLJZV/Jo1d7F+3kyyiK0XCv5CMvbt8=; b=DSQI1XMCsLYq1+FFcs49laMuUvRqJHYIXpBLLaSTqmNjyOdqlc/aNuvN2wWQW+mf DWRZaKNB1YbI/58yUwo1oyUIMhrNgtjgwcVOZsXWRK3Ynf2tulTAQhdKROLlFXyFVW0 3ZVoxwTZj9yg3OKgDC1Ah1l8IrCnhPa9HXz7bA0Y= 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 In-Reply-To: <20210420123913.74ejllmgty5z2w6k@anna.jacobs.jacobs-university.de> Date: Wed, 21 Apr 2021 23:08:54 +0000 Cc: "netconf@ietf.org" , YANG Doctors Content-Transfer-Encoding: quoted-printable Message-ID: <01000178f6b18c8b-1b707cda-9404-4617-9301-3fe6846fcad7-000000@email.amazonses.com> References: <161045360252.14510.16755799701987783827@ietfa.amsl.com> <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com> <20210416115004.fqhitq6jofc6vjih@anna.jacobs.jacobs-university.de> <01000178ec7bfedf-5b8a2940-2fdd-42f5-ae43-27277d991769-000000@email.amazonses.com> <20210420123913.74ejllmgty5z2w6k@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.21-54.240.48.93 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 23:09:00 -0000 Hi Juergen, Firstly, I=E2=80=99m beginning to think that my SMTP-client might be the = source of the =E2=80=9Cgarbling=E2=80=9D we=E2=80=99ve been seeing in = some off the text messages. It was updated a couples weeks ago, and = I=E2=80=99m still running the current version. Checking = =E2=80=9Cpreferences=E2=80=9D, I see that my =E2=80=9Cuse same format = from original message=E2=80=9D setting was disabled - I just reenabled = it. More below. K. >> Ah, now I understand, you mean to remove the XML2RFC v3 b >=20 > Ah, its called an "aside". I am still reading plain-text but the > question likely is what belongs into an aside box and what into > text. For me, there is no reason to put this sentence into an 'aside' > box - whatever the purpose of such a box is. Its just a regular > sentence for me. >=20 =46rom https://tools.ietf.org/html/rfc7991#section-2.6: "This element is a container for content that is semantically less important or tangential to the content that surrounds it.=E2=80=9D= Is it okay to leave for the Copyeditor? >> Yes, the diagrams would be a nice addition to an 8340bis. Also, I = don't know if you noticed, but the =E2=80=9CData Model Overview=E2=80=9D = section I created in all these drafts is highly mechanical=E2=80=A6somethi= ng that could be mostly automated=E2=80=A6perhaps a good student = project? ;) >=20 > Students tend to do something half and then disappear. ;-)=20 :laugh: K. From nobody Wed Apr 21 18:01:41 2021 Return-Path: <01000178f7189888-4d8f72aa-7bf1-4875-af4c-ecde0f0d2ba5-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 4F5A83A3DF3; Wed, 21 Apr 2021 18:01:31 -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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 EjpMzoOTsJNn; Wed, 21 Apr 2021 18:01:29 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1636D3A3DBE; Wed, 21 Apr 2021 18:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619053287; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=aGMsO2q3uIVXnvHonbnXT7OvyTAIs9ulr/5/dTn+EpI=; b=iB6XhgIjQFvCODb0jXMBTjKbRFiqi+ZUFq2Z13W+9DVuqUoAkRndFZSqYV6pkZYm fNuMd1TdbzV4LfnAvseqZrkafGBsNHCSWlb98GxfD02uBfzPRhdLH3M8AtX5XT5iO9Y SUOst0k7b4lhwsJxA0eCC6K5oTmkhLX2D5L5XYDU= 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 In-Reply-To: <87tuo1w2j2.fsf@nic.cz> Date: Thu, 22 Apr 2021 01:01:27 +0000 Cc: YANG Doctors , draft-ietf-netconf-tcp-client-server.all@ietf.org, last-call@ietf.org, "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000178f7189888-4d8f72aa-7bf1-4875-af4c-ecde0f0d2ba5-000000@email.amazonses.com> References: <161796231010.8005.7390142571009530431@ietfa.amsl.com> <01000178ebd39133-87ef25f3-1047-4f02-b5fb-706e82e7c02a-000000@email.amazonses.com> <87tuo1w2j2.fsf@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.22-54.240.48.93 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-tcp-client-server-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 01:01:32 -0000 Hi Lada, >>> **** Comments >>>=20 >>> - Sections 2.1.4, 3.1.3, 4.1.3: the sentence 'The "..." module does = not contain >>> any protocol-accessible nodes.' is misleading in that the modules do = define >>> data nodes that are intended to be protocol accessible after the = corresponding >>> grouping is used. I know this is a part of the NETCONF/YANG lingo, = but another >>> formulation that clearly says what's going on might be preferable. >>=20 >> Fair enough. How about this? >>=20 >> The "ietf-tcp-..." module does not itself define >> any protocol-accessible nodes. This module defines >> only "grouping" statements that are used by other >> modules to instantiate protocol-accessible nodes. >>=20 >=20 > What about using just the last sentence? It says all. Done. >>> - Sections 2.2, 3.2 and 4.2: the XML snippets use document elements >>> "tcp-common", "tcp-client" and "tcp-server", but these containers = are not >>> defined in the corresponding modules. This is confusing, my = suggestion is to >>> rewrite the examples in the JSON representation where no such = top-level node is >>> necessary. >>=20 >> Indeed, and my validation script even takes the special step to = convert the groupings to containers in order for the validation to = succeed. In other modules, I created a =E2=80=9Cfoobar-usage.yang=E2=80=9D= module to instantiate the grouping statements. >>=20 >> Hmmm, I was about to create the JSON, but realized that it would be = easier to strip out the first-and0-last lines from the XML examples. I = understand that they're not a valid XML documents, but snippets have = been used before=E2=80=A6 >>=20 >> FWIW, all the examples are still validated, so there=E2=80=99s = otherwise no loss in correctness. >=20 > Maybe it is not necessary to validate these short fragments. In any = case, a casual reader might be confused - where do these elements come = from? As a minimum, some explanation should be added. Done - the following XML-comment has been added just each such XML = example: I think it critical to validate *every* example, as it=E2=80=99s too = hard to maintain otherwise. ;) >>> - What is the purpose of "tcp-connection-grouping" if it only uses >>> "tcp-common-grouping" and nothing else? Why cannot = "tcp-common-grouping=E2=80=9D be used directly? >>=20 >> I added this comment: >>=20 >> Whilst this grouping appears to not add any value beyond that = given >> by "tcp-common-grouping", it is defined so as to provide space for = a >> future peer module (e.g., "tcp-system-grouping" that defines = additional >> configuration nodes used to configure a TCP stack at an operating >> system level. >=20 > OK, so this new grouping could use equally well either = "tcp-connection-grouping" or "tcp-common-grouping", and add more = configuration nodes. Having two names for the same thing is confusing. Removed, after reviewing the latest "draft-ietf-tcpm-yang-tcp=E2=80=9D = draft. >>> - The "local-port" parameter defined in ietf-tcp-client seems = dubious from the >>> security viewpoint in that fixing the source port makes it easier = for attackers >>> to steal the connection (see RFC 6056). >>=20 >> Interesting read. But note that the RFC regards primarily cleartext = protocols. An axiom in security circles is =E2=80=9Cobscurity is not = security=E2=80=9D, i.e., randomizing client ports to make off-path = guessing harder is not much of a win. >=20 > I don't think this can be labelled as security by obscurity. Without = cryptographic protection, it is basically the only available measure = against traffic injection. In DNS, for example, source port numbers (and = transaction IDs) with insufficient entropy are considered security = issues. Noted. >>> If the feature >>> "local-binding-supported" is needed at all, I'd suggest to mention = this in >>> Security Considerations. >>=20 >> =E2=80=9CNeeded=E2=80=9D is an interesting take. My feeling is that = the model is >> incomplete otherwise. =46rom a Security Considerations perspective, >=20 > I was thinking it might be needed for cases like NETCONF call home. = Otherwise, it is not common to be able to configure the port for the = side that performs active open. Uncommon, but not unheard of, nor bad practice. Ever since I worked at company developing FW/IDP devices and a NOC/SOC, = I=E2=80=99ve always pushed for and advocated the ability to configure = local address/ports. >> I=E2=80=99d like to put something like: >>=20 >> =E2=80=9CImplementations are RECOMMENDED to implement the = 'local-binding-supported=E2=80=99 feature for cryptographically-secure = protocols so as to reduce to attack surface presented by firewalls.=E2=80=9D= >=20 > I don't understand what firewalls have to do with this issue. Because knowing the source addr/port enables some of the 5-tuple numbers = to move from an =E2=80=9Cany=E2=80=9D value to specific values. This = benefits both the egress and ingress sides. > On the other hand, I would also mention the reason why this is = RECOMMENDED, and cite RFC 6056. Done. >> Is that what you had in mind? If nothing else, having such a = statement in the draft would certainly catch the eye of the SecDir = reviewer. Thoughts? >=20 > Of course, a SecDir review would be more authoritative here. >=20 > Cheers, Lada K. From nobody Wed Apr 21 18:26:39 2021 Return-Path: <01000178f72f82b2-465a9684-f2b7-4872-bed1-950216c323b9-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 C95F33A3EB8; Wed, 21 Apr 2021 18:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 Rdo2hDg1nNyr; Wed, 21 Apr 2021 18:26:31 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4123A3E85; Wed, 21 Apr 2021 18:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619054789; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=VZyZz1gP9+wRpSWSHnnzWaExRahye76i9vg2gNr7ZDM=; b=Z2yx3n8VwyqWEDVZeKab6VLOq0zs4+dChpa0SfLoxEi9MeNe21gGoG/3W+Tgp9SJ yxFVEvNAwuL93Puj9kQwumBnRF4EuOgRTk+58pG3FOrPel6IlQuCoUMe5dNvxxvXSbc gAajr8EjZ1kheS0PJBEUF/RCyrbVEe8hca9y8h+g= 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 In-Reply-To: <20210420124415.jjwl6nlh72obeurd@anna.jacobs.jacobs-university.de> Date: Thu, 22 Apr 2021 01:26:29 +0000 Cc: YANG Doctors , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000178f72f82b2-465a9684-f2b7-4872-bed1-950216c323b9-000000@email.amazonses.com> References: <161064362767.26403.10249622617283363882@ietfa.amsl.com> <010001778e68398d-c2bff7b8-4c4e-4f30-a962-1ce39e2ece13-000000@email.amazonses.com> <20210416123749.246d6irnd3oso3x4@anna.jacobs.jacobs-university.de> <01000178ece4d8fd-09010867-cbff-486e-b598-3653e944b833-000000@email.amazonses.com> <20210420124415.jjwl6nlh72obeurd@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.22-54.240.8.88 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-keystore-20 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 01:26:34 -0000 Hi Juergen, >> It took me while to determine what text got clipped above which you = think is better. Let me clarify, you think that it would be better to = both: >>=20 >> OLD; keystore-supported >> NEW: central-keystore-supported >>=20 >> *and* >>=20 >> OLD: =E2=80=A6 the keystore, when this module is implemented >> NEW: =E2=80=A6 the central keystore, when this module is implemented >>=20 >> Correct? >=20 > Yes. Done! Thanks again. K. From nobody Wed Apr 21 23:15:35 2021 Return-Path: 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 8126C3A148E; Wed, 21 Apr 2021 23:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=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=jacobsuniversity.onmicrosoft.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 0aLW5W5I7bsg; Wed, 21 Apr 2021 23:15:30 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE33A3A148C; Wed, 21 Apr 2021 23:15:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OCGeBSsUTOa2QEbCm09swbv0qfD2TWuZY49iuZEQmnQEGDUNhLk1VgdcatRMMy6EJqUj3VwoCo4ZLxjRMerBUYyOaqKxwuv1DRlYsgvxv6GuzCAynlXrd7H//wWnPs5WycsfmyhatiJd2Mo3Ngs6MBi0+tq7YkaX6cqeTmWzwiHt6ATtrJlHipqIZXeScB38hUivAHVogM/a7deItZDO68y8gHN16WOcEZRsXhhcg7+CJH+7ZJ289CKEYnPw3Vfc/ArzXKZQxenNzkrlGcwPqwZ9Qb9Im7O91gwh1rMGYF3IaJ+hiMc6LcxK8jnAbVqXz50ti+1N8ktZWlLT3VP7aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C5U6QHzqGi4q1b6g8J/n/PHXzeB/dTH4LrhaKaUEZwg=; b=LPMosNV7r8u8AEr9ttX2oytI2OQrbAZBh8Yq8MkprGTUXqAk3sP943oUZyidzD78ev+GbTCJzt+OC6q12paBEZWxydS7vJCo0uoqFR3TyMYrKRAh43U9qvgCmIjpQsfMt4OKbdrLD6euZJs6FuOAoGRnRNIuF6idNld2xrZM2rz0cLdRz7wECxJaS0PcvFxMl3FY+bde5hccdq0K0B5rrq2RP4tPXbR6/TkByML3XBkDh6xk1JvTku600dxwtu5Wotm/z/rc+3oX8wnSlsugG6ZhunfQkj+NCSevOuA5ohnq5mmkP4ZYFewC6lm8fkcnastyWllXpTL8DaCs0XHV1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C5U6QHzqGi4q1b6g8J/n/PHXzeB/dTH4LrhaKaUEZwg=; b=XTTFQbDpJHqY1qvnqADrB/Nhmtwvg/jgUDIg08PenBtMXiY0Skgl7YjfcpZ7lkbZIM55waB4jPNXJIlL0ZOXgkqVRfZIJcEEdo1Mg+iDKBCCpowcXw5HDu0p3JMXdLuuLtdYMF9QkDxTpufB8ksN+FTJQjMIBE/HSUFsUlRcAmM= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1043.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:26c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Thu, 22 Apr 2021 06:15:15 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.024; Thu, 22 Apr 2021 06:15:15 +0000 Date: Thu, 22 Apr 2021 08:15:13 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: "netconf@ietf.org" , YANG Doctors Message-ID: <20210422061513.uvdte37xafvkzmco@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" , YANG Doctors References: <161045360252.14510.16755799701987783827@ietfa.amsl.com> <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com> <20210416115004.fqhitq6jofc6vjih@anna.jacobs.jacobs-university.de> <01000178ec7bfedf-5b8a2940-2fdd-42f5-ae43-27277d991769-000000@email.amazonses.com> <20210420123913.74ejllmgty5z2w6k@anna.jacobs.jacobs-university.de> <01000178f6b18c8b-1b707cda-9404-4617-9301-3fe6846fcad7-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01000178f6b18c8b-1b707cda-9404-4617-9301-3fe6846fcad7-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR2P264CA0037.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101:1::25) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR2P264CA0037.FRAP264.PROD.OUTLOOK.COM (2603:10a6:101:1::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.22 via Frontend Transport; Thu, 22 Apr 2021 06:15:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6c847c16-9403-456a-2200-08d90555fe73 X-MS-TrafficTypeDiagnostic: AM9P190MB1043: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Y2I4o1BnOCZ2s0fH2PLCazyM8QBnHdQeBeffrLfTKKoS5+DevLJQdEEENH/BqDlcxTHoQp9ahnXE9t6tVKwvRNcyYFmTnVFQsf1cGy8qqz0qsg78IRksxaO9U+HQ917V9ZzdafoJp5CleUQ8+uptYTeG+pjQcfNF4Zn046kxBDfyp3UwLrF5cayLrb4CPf1eIbCkENEQb8LRLawPmtPMcm9dWYMgE9lXYFwg/7pk6y2NniosWn9blnMUG7naRxwAv/tvNQ/PJue8gHG8Ih+6ktrIxCbOz2sO88lvdgQtbUpum3j8T9QFY6IP7yJXGZ0xtzQG/T5HDxD6n8f30bj5+eplz3ZtF3DjWvDLYruC9pY0FIvj4JoI3pevtpHTi0SdwFBnrRoanuXaObwaanFTkuYmHlV73L/wtPkMCm48YESuy5uJFEqvKDIiNy8Q70R/n7FiQ2VJLRo0L3kPudAJqRvf3oeAfKN4GzfWOW9d9kSou+O3lvqKDLrstuaowfu7hWO3lynP3BG5T2LLuvVLomJYzGbWPoLeVnf0Lki/GCTLq86v2cV1P//j6WnIBRCWI9e+C641bRG7j8FhhtqPjW/oThrU1yJLeSwBsWroew2z0Qdm8JMvLmAWpP6gP1el0CB7mWw9b/VkxS5CMs+9ng+RQgU6lGbLdClRg/kzoZ0M2HZstZKOCMgkPVnnniofoKnmvID08hpm1X6swyr9+l+BNvaXj/xpzIIt0ozHHbg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(396003)(346002)(136003)(39840400004)(376002)(26005)(3450700001)(6486002)(66946007)(8676002)(956004)(66556008)(966005)(5660300002)(66476007)(2906002)(54906003)(316002)(86362001)(478600001)(786003)(38100700002)(38350700002)(1076003)(4326008)(6496006)(186003)(8936002)(16526019)(52116002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?SXg0TUgwYXBrTGgrdk02N2JDcW5vL1Z2WHJIZWJKYVk5Z3poL2tnM2MweEtk?= =?utf-8?B?YldyekRqQTRQT1hONjBPeVZKTWlVREp5TjR0U3htVnltU0dPdUVEbU5TQ0pE?= =?utf-8?B?ajh1QkRZTEVqNmFrbSt3bXhvTzI4S3d6bUVLeUxNVDFpei9qR0V1RnJvSGVw?= =?utf-8?B?bzVlUFh1NVNzKytpY3RMWDhRTUt0MnhmeVpDSlEyYzJoUlZ1T2M1VXZ4R3Nj?= =?utf-8?B?TDFEOTg5Q01LV2hoZ1ovYVEvTWZEOGpzMFFYSmMvTVlTMm5qY1BMY2lDNWlC?= =?utf-8?B?WjBpbFlVa1RSYVdPSVdyMzArb0dheHdoS3RaVGNWWTdLMHhSY0tnN3YzTkFP?= =?utf-8?B?Z3NjVFFtWUZJZGp1WDFqM2dQN0F3bUxPaU14S2xEaFNnd2FKOVZLQzZVMFdv?= =?utf-8?B?ckQwUHluTml3dUZ4ZlJBNkRWS0ZLQWdTNjl5VmlKSmJhRnRHK2oxcjZheWNS?= =?utf-8?B?VXRaZlNLRm5rSnpGL2NFTzZRMm9CM3hsWWFVdGZWdkhNcUlpN1dPTk1DSkZo?= =?utf-8?B?clFqbnI1REZHWSs3RXB3bk0zV3NUZ1hpTm05OVRtS1k4bUJDY2M5bW41QjEx?= =?utf-8?B?WGtDR3dwWTNGSW1McW5YVW0yUHhrQWJWMkVJNERLRkpUN2ZNNWZRNjBrZzN3?= =?utf-8?B?Y0FiMTJ3NURZdlY2Uno3U2loSS9ZcFduVG50U0tuZDFyeUJWZ1pUd1A5MjdO?= =?utf-8?B?YjRobjVNLzE2Q0trWC9OU2Nhb004Z2RwM1JncVVKelZNbFg0SkFaY2xCWHBS?= =?utf-8?B?aGR2eEhrZTYrMlgvMjJuUWoyRkVUS2RjdTdvbkU5WFVXTHByZVRNV2N0T0JO?= =?utf-8?B?bGJtS3pRNXBHQTl1bUJoZmF3cUh2RmlHNlFpN3JxalVndkZnMlZFQk9tVnBF?= =?utf-8?B?bVdZSzU0QWs4eFhaRi8reFBhNkUvUFVuM1h0QjFNQkNkUEwyYms5dGZXakZa?= =?utf-8?B?VGExY2c2aGlqck53R2FVNDlGTFA4REhFK0NHQjhUcFhaekRLNm5ZYUdORGc1?= =?utf-8?B?emVMZHpldDNXRzcxaUl1aWJpRUtkQzdDdjNGT0tPd1JNQjF2ZmdCUVI2Nm9U?= =?utf-8?B?Yk9IMHd4blRPZndtWkhub3pRVWtVUmQrOHQ5RitFV0NTVWkxUjM4ZnVHVnU2?= =?utf-8?B?RkZKYmpZQUV6eHNTenF0WXJpNWswTW9MeVFZZkFyQXlHdXhkdzZJOEhwakhX?= =?utf-8?B?cExGeFBzNzVycFlLTTcvV0h0bGFmOXZtU25PbFZtSFhzUVI1QU1TaHNlZ21a?= =?utf-8?B?dlJqeVZlek1BWDFsL2xjRnYvcEJnZm14Zmsyck52dWZIbk5JZFFleC91NGxG?= =?utf-8?B?dWVFVFVkSy9Yb1hCTm5YMEFuVjZRT0NYWDdlSll3ME94ZWhRSjlmUTNLMFdv?= =?utf-8?B?V0loMEc1ZjM5QkJVNjRrMVZiOFNzc09VclFTaGhwMmFqMHJmWE5sbFJvdzZs?= =?utf-8?B?bGUwbHhDK3RBdGgzcWZMbmxBNkpVNUlOeW1BRzBUQ2ZCOTM4a24rTUpVSmNM?= =?utf-8?B?akRVeWduR3lQTjduMU43eVZUc0hUSlZKV3F6Z0hiKzZtblZtQkV5cHZHWEFE?= =?utf-8?B?N3dMamVWZVVJZExzak9wb3RGeUJCQ2VQckJ6NzYrWkZpbXFVUEVZek9IM2JX?= =?utf-8?B?OTJ1SmRVR1dCeWlGUWRFa2tqL21YakNMSnppcXlleTZWREpZb0NlSkZwMkVU?= =?utf-8?B?TCthVjJvTUk3UFZnUWF5L25TZE9ZMTQxNG5QZDBGenNmZDRrMzY3QzBnVStN?= =?utf-8?Q?5tEvxFv2sllsisiuX0vP+H0n2C+882ZpLupC88D?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 6c847c16-9403-456a-2200-08d90555fe73 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2021 06:15:15.0068 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0g10KPE/54WFoYBq/80msiCEOVHtc3jZcEyjF6VVmOxCmLHwKRN6WrHjiVxS5jQcXUj7YZ6PhR9tpa787hMFVCfuDATucehpE7OqRmzEotg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1043 Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 06:15:35 -0000 On Wed, Apr 21, 2021 at 11:08:54PM +0000, Kent Watsen wrote: > > >> Ah, now I understand, you mean to remove the XML2RFC v3 b > > > > Ah, its called an "aside". I am still reading plain-text but the > > question likely is what belongs into an aside box and what into > > text. For me, there is no reason to put this sentence into an 'aside' > > box - whatever the purpose of such a box is. Its just a regular > > sentence for me. > > > > From https://tools.ietf.org/html/rfc7991#section-2.6: > > "This element is a container for content that is semantically > less important or tangential to the content that surrounds it.” > > Is it okay to leave for the Copyeditor? > Sure, it was simply the first time I have seen this new structural element. I hope we do not end up in the future discussing what is "less important or tangential content", whether its normative or not etc. Sometimes less is simpler. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 22 00:10:51 2021 Return-Path: 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 76B233A18A3 for ; Thu, 22 Apr 2021 00:10:50 -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 H2y0-AxmxVPy for ; Thu, 22 Apr 2021 00:10:45 -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 42D393A18A1 for ; Thu, 22 Apr 2021 00:10:45 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id D67966007A; Thu, 22 Apr 2021 09:10:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619075436; bh=KitN6y7mVew33NqfhTEOpfL9HUNq0JWjQZ1QW7DVJs0=; h=From:In-Reply-To:Date:Cc:To:Subject; b=B+++YN3nhtuaHTpTJx0ZXrmJwhtJD7QnpWWiFEvOCCfWCS1Hnp5RvaHYYcmVMQ5ga Ve2vpimWbpvPnzd8tCWqBU52imqlVDfYLVkbQu55iJ/475yBa24Tnmnt08pQeri3DT pJpDgZqBw/v3v4FerhFZ10kLHydv4lsqpAl0lIak= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <01000178f67acd58-2e857cd4-cafe-46bc-979b-712e5f777d28-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Thu, 22 Apr 2021 09:10:36 +0200 Cc: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <1108-60812180-37-670e7400@130038994> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 07:10:51 -0000 Hi Kent, > Hi Michal, > > >> My understanding that you =E2=80=9Cthink" these updates are okay, = which is greatly appreciated (your considerations, that is). It would= be perfect if you could actually try them out before this work gets pu= blished... > > > > Yes, that is exactly what I meant. Unfortunately, I am terribly bus= y and I am just not able to implement all these modules. Even if they g= ot published today, I think it would take us at least several months ti= ll we are able to use them. > > Noted. > > > >>> An improvement I can think of is to put all the authentication me= thods in "users/user" in a mandatory choice. The authentication methods= would be one case, while something like "global-config" (empty leaf, f= or example) would be the other. That should allow for maximum versatili= ty when one could configure the 'global authentication methods', enable= the "client-auth-config-supported" feature to configure the recognized= users, but use the global authentication methods settings for some/all= the users (not having to configure each one separately). Because that = will probably be our use-case. > >> > >> Could you provide a tree diagram snippet that illustrates this? R= egarding your last sentence, I imagine that that might be many folks us= e-case. That is, the actual user-auth might be somewhere else (e.g., P= AM, LDAP, etc.); it might be rare thing that folks would want to config= users inside the =E2=80=9Cssh-server-grouping=E2=80=9D. > > > > I wanted to, but quickly learned that I did not understand this YAN= G part correctly. It seems every client authentication method has its o= wn feature AND a leaf or container in {grouping:ssh-server-grouping}/cl= ient-authentication/supported-authentication-methods that marks support= for the authentication method, again. Why the redundancy? > > The "{grouping:ssh-server-grouping}/client-authentication/supported-a= uthentication-methods=E2=80=9D container is solely for enabling the SSH= -server know which authentication methods to present to the client duri= ng the handshake. > > The "{grouping:ssh-server-grouping}/client-authentication/users=E2=80= =9D container is a locally-defined list of users and credentials that c= an be used to authenticate them. > > In theory, the "supported-authentication-methods=E2=80=9D could be de= rived as the union of the methods configured for each user, but at some= point the =E2=80=9Cca-certs=E2=80=9D and =E2=80=9Cee-certs=E2=80=9D we= re pulled out of that container, and so that can=E2=80=99t be the case = anymore=E2=80=A6assuming it was ever a good idea in the first place... I suppose I was not clear enough, the seeming redundancy is in all the = specific client-authentication features AND the "supported-authenticati= on-methods". You must both enable a feature and create the correspondin= g leaf/container to actually support the method. But it seems enabled feature marks something like a capability of the s= ystem to support the authentication method and the data whether you act= ually want to advertise the method for new SSH clients. I am not sure t= his distinction is needed, though. It seems to me the "supported-authen= tication-methods" container can be removed altogether and the advertise= d authentication methods will simply be all the configured ones for the= user. > > Regarding the client authentication configuration, which is a separ= ate issue, I suppose the most generic solution would be to model it the= same way certificates and some other things are. Meaning, to have a se= parate container with a list of client-authentication configurations. T= hen, every {grouping:ssh-server-grouping}/client-authentication/users/u= ser will have to reference one. That should allow support for all kinds= of scenarios, including one where there is only a single client-authen= tication configuration and all the users reference it. > > This is where your providing a snippet of a tree diagram would be hel= pful. Hopefully, with the above explanation, you're more able to do th= at now=E2=80=A6? I am sorry, I have still not adjusted to the fact that the modules now = include all the configuration needed, with nothing being read from the = system. Having understood this, I think the current principle of per-us= er configuration is fine, there is no other solution. But to fully configure the "keyboard-interactive" method, there is some= more information needed. I have looked at how libssh and OpenSSH sshd(= 7) configure this method. Starting with sshd, it relies on login or PAM [1]. I do not have any ex= perience with PAM so I do not know how exactly that is supported in the= se YANG modules. But as for login, it seems to basically duplicate the = functionality of the "password" authentication [2]. That is my experien= ce as well but I do not know any more background for this. So, the conf= iguration would again be simply a "password" leaf. As for libssh, it went for a completely generic solution in which you m= ust specify the method name (which maps to the "submethod" would be my = guess), the instruction, and a list of challenge-response prompts [3]. = We have implemented the simple password authentication this way [4], wh= en the password is read from the system (the login functionality, actua= lly). Going with this full configuration, the instruction and a list of= challenge-response prompts (with echo configuration) should be added t= o "{grouping:ssh-server-grouping}/client-authentication/users/keyboard-= interactive/submethod=E2=80=9D. Actually, why is "keyboard-interactive"= a list? A container should be fine and "submethods" should probably be= a list instead. That is all the feedback I can provide for the "keyboard-authentication= " method. I could even suggest the exact YANG changes if needed but I a= m missing the information about PAM support, if nothing else. Someone e= lse could add something in case I missed anything and it would be great= if you could find someone actually using the "gssapi" methods to provi= de similar feedback, otherwise you will likely have to rely on addition= al modules adding some augments, which is not an ideal solution. [1] https://linux.die.net/man/5/sshd=5Fconfig (search for ChallengeResp= onseAuthentication) [2] https://www.freebsd.org/cgi/man.cgi?login.conf(5)#end (section AUTH= ENTICATION) [3] https://api.libssh.org/stable/group=5F=5Flibssh=5F=5Fserver.html (f= unction ssh=5Fmessage=5Fauth=5Finteractive=5Frequest) [4] https://github.com/CESNET/libnetconf2/blob/master/src/session=5Fser= ver=5Fssh.c#L809 > >> The following regards the "tls-listen or tls-call-home or sshcmn:s= sh-x509-certs=E2=80=9D if-feature statement: > >>>> But I wasn=E2=80=99t trying to fix your original issue. As ment= ioned, there is a YANG-next issue and the best that consuming modules c= an do is to 1) enable all the features defined in these modules and 2) = augment-in =E2=80=9Cuse=E2=80=9D-specific feature statements where the = groupings are used. > >>> > >>> Okay, I suppose this can be done although it seems to me like a m= inor deviation (the augment solution). What is the reason for not havin= g the module this way out-of-the-box? > >> > >> It might be helpful to recall that this =E2=80=9Cif-feature=E2=80=9D= statement is in the netconf-client-server draft, and thus likely shoul= d be discussed in another thread. That said, we=E2=80=99ve come so far= already, so why not a little more, right? ;) > >> > >> So, do you have a proposal mind? > > > > Right, we are getting OT, too bad :) I have attached a diff that fi= xes my concerns and I think it also makes for a more intuitive tree dia= gram. > > Your diff points in a direction that looks good to me. I wish you=E2= =80=99d proposed it originally ;) > > How does this commit look? https://github.com/netconf-wg/netconf-cli= ent-server/commit/29523cfb2a8561c578fad7aaf36107bc7ecd5afb Um, I do not think that works. It took me a while to understand but bas= ed on the comment, you tried to add the "sshcmn:ssh-x509-certs" if-feat= ure to the "client-identity-mappings" container. To my knowledge, what = you actually did was augment-in no new nodes to the "client-identity-ma= ppings" container, but making 'all these no nodes' conditional on an if= -feature, none of which makes sense. The "if-feature" in an augment rel= ates to the "augment" itself, not to its target, you can only add new n= odes with an augment. > BTW, this introduces an issue as to if =E2=80=9Cclient-identity-mappi= ngs=E2=80=9D are required for SSH when certs are used, or if the SSH us= ername that is built into the protocol (and used in al non-cert scenari= os) 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 experie= nce, I would naively guess that it means you are using certificates ins= tead of SSH keys, which seems to me is relevant for the "hostbased" and= "publickey" authentication methods and would, in-effect, replace the c= onfiguration of these methods. But that is not what is found in these Y= ANG modules so I guess I am wrong. Regards, Michal From nobody Thu Apr 22 12:21:16 2021 Return-Path: <01000178fb076531-6b172846-f310-4c85-ac7f-33cdd699698c-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 A918D3A0D03 for ; Thu, 22 Apr 2021 12:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 HwW812SUTNbC for ; Thu, 22 Apr 2021 12:21:11 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE61D3A0CFE for ; Thu, 22 Apr 2021 12:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619119269; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=aZtXTVxUFFqsUl5OFiJavcOIlnEEnESKXrbbFTIttNg=; b=gAmhL2+u2l6zahWMfiDg3YvuHF+bJ+sDg2rTP5E3jQwWOqve5NKfhyf8XswDTg0A SiC/DwIce6uwhssrDMYX+T8iSA+rivL94N9mdWmrx7Go3eQiDfby7xvc4lmV5ERXMkE PnvuZl+8WvnyXZoA0lmohppey7LCB4kLWxXuxiSg= 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 In-Reply-To: <1108-60812180-37-670e7400@130038994> Date: Thu, 22 Apr 2021 19:21:09 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000178fb076531-6b172846-f310-4c85-ac7f-33cdd699698c-000000@email.amazonses.com> References: <1108-60812180-37-670e7400@130038994> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.22-54.240.8.96 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 19:21:16 -0000 Hi Michal, >>>>> An improvement I can think of is to put all the authentication = methods in "users/user" in a mandatory choice. The authentication = methods would be one case, while something like "global-config" (empty = leaf, for example) would be the other. That should allow for maximum = versatility when one could configure the 'global authentication = methods', enable the "client-auth-config-supported" feature to configure = the recognized users, but use the global authentication methods settings = for some/all the users (not having to configure each one separately). = Because that will probably be our use-case. >>>>=20 >>>> Could you provide a tree diagram snippet that illustrates this? = Regarding your last sentence, I imagine that that might be many folks = use-case. That is, the actual user-auth might be somewhere else (e.g., = PAM, LDAP, etc.); it might be rare thing that folks would want to config = users inside the =E2=80=9Cssh-server-grouping=E2=80=9D. >>>=20 >>> I wanted to, but quickly learned that I did not understand this YANG = part correctly. It seems every client authentication method has its own = feature AND a leaf or container in = {grouping:ssh-server-grouping}/client-authentication/supported-authenticat= ion-methods that marks support for the authentication method, again. Why = the redundancy? >>=20 >> The = "{grouping:ssh-server-grouping}/client-authentication/supported-authentica= tion-methods=E2=80=9D container is solely for enabling the SSH-server = know which authentication methods to present to the client during the = handshake. >>=20 >> The "{grouping:ssh-server-grouping}/client-authentication/users=E2=80=9D= container is a locally-defined list of users and credentials that can = be used to authenticate them. >>=20 >> In theory, the "supported-authentication-methods=E2=80=9D could be = derived as the union of the methods configured for each user, but at = some point the =E2=80=9Cca-certs=E2=80=9D and =E2=80=9Cee-certs=E2=80=9D = were pulled out of that container, and so that can=E2=80=99t be the case = anymore=E2=80=A6assuming it was ever a good idea in the first place... >=20 > I suppose I was not clear enough, the seeming redundancy is in all the = specific client-authentication features AND the = "supported-authentication-methods". You must both enable a feature and = create the corresponding leaf/container to actually support the method. >=20 > But it seems enabled feature marks something like a capability of the = system to support the authentication method and the data whether you = actually want to advertise the method for new SSH clients. I am not = sure this distinction is needed, though. The =E2=80=9Cfeature=E2=80=9D indicates if the server supports that = configuration at all. For instance, there may be an SSH server that = only supports =E2=80=9Cpublickey" or only X509 certs. The feature gates = what can be configured, long before a handshake. > It seems to me the "supported-authentication-methods" container can be = removed altogether and the advertised authentication methods will simply = be all the configured ones for the user. The "supported-authentication-methods=E2=80=9D are to know what list of = auth-methods to present to the SSH client during the handshake. It = would be ideal if this list could be derived from either =E2=80=9Cfeatures= =E2=80=9D and as the union of the methods configured for each user. Looking at RFC 4252, Section 5.1 (Responses to Authentication Requests) = says: If the server rejects the authentication request, it MUST respond with the following: byte SSH_MSG_USERAUTH_FAILURE name-list authentications that can continue boolean partial success The 'authentications that can continue' is a comma-separated name- list of authentication 'method name' values that may productively continue the authentication dialog. It is RECOMMENDED that servers only include those 'method name' values in the name-list that are actually useful. However, it is not illegal to include 'method name' values that cannot be used to authenticate the user. Already successfully completed authentications SHOULD NOT be included in the name-list, unless they should be performed again for some And Section 5.2 (The "none" Authentication Request) says: A client may request a list of authentication 'method name' values that may continue by using the "none" authentication 'method name'. If no authentication is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of methods that may continue in its 'authentications that can continue' value. So my reading is that the list of auth methods SHOULD be user-specific = but MAY be (dare I say) feature-specific. In either case, it seems that = an explicit "supported-authentication-methods=E2=80=9D may be too much. = I=E2=80=99m tempted to remove it... >>> Regarding the client authentication configuration, which is a = separate issue, I suppose the most generic solution would be to model it = the same way certificates and some other things are. Meaning, to have a = separate container with a list of client-authentication configurations. = Then, every = {grouping:ssh-server-grouping}/client-authentication/users/user will = have to reference one. That should allow support for all kinds of = scenarios, including one where there is only a single = client-authentication configuration and all the users reference it. >>=20 >> This is where your providing a snippet of a tree diagram would be = helpful. Hopefully, with the above explanation, you're more able to do = that now=E2=80=A6? >=20 > I am sorry, I have still not adjusted to the fact that the modules now = include all the configuration needed, with nothing being read from the = system. Having understood this, I think the current principle of = per-user configuration is fine, there is no other solution. I=E2=80=99m unsure if =E2=80=9Cnothing being read from the system=E2=80=9D= is accurate. Yes, this has been a thought, but I think it falls into = two broad categories: 1) per-user credentials (e.g., passwords in = /client-authentication/users)=20 2) user-independent credential authenticators 2a) configured PKI issuers (e.g., =E2=80=9Cee-certs=E2=80=9D and = =E2=80=9Cca-certs=E2=80=9D) 2b) configured callout mechanisms (e.g., PAM, LDAP, Radius, etc.) Some comments: - we do not yet have anything in the model representing (2b) - (1) could always be viewed as something that should be provided by a = (2b) > But to fully configure the "keyboard-interactive" method, there is = some more information needed. I have looked at how libssh and OpenSSH = sshd(7) configure this method. >=20 > Starting with sshd, it relies on login or PAM [1]. I do not have any = experience with PAM so I do not know how exactly that is supported in = these YANG modules. But as for login, it seems to basically duplicate = the functionality of the "password" authentication [2]. That is my = experience as well but I do not know any more background for this. So, = the configuration would again be simply a "password" leaf. >=20 > As for libssh, it went for a completely generic solution in which you = must specify the method name (which maps to the "submethod" would be my = guess), the instruction, and a list of challenge-response prompts [3]. = We have implemented the simple password authentication this way [4], = when the password is read from the system (the login functionality, = actually). Going with this full configuration, the instruction and a = list of challenge-response prompts (with echo configuration) should be = added to = "{grouping:ssh-server-grouping}/client-authentication/users/keyboard-inter= active/submethod=E2=80=9D. I very much agree with modeling after how other well-known servers are = configured. One thing for sure, per-user passwords, public keys, and = the like are NOT configured in sshd_config (they=E2=80=99re in a = per-user directory, accessible via PAM, presumably). Per auth method: - hostbased: - specifies all config via: - HostKey, HostKeyAlgorithms, and HostbasedAuthentication - password: - config just flags: PasswordAuthentication., PermitEmptyPasswords - but /etc/passwd typically used - publickey: - in sshd_config, a callout can be configured via = AuthorizedKeysCommand - ...but ~/.ssh/authorized_keys typically used - keyboard-interactive - config just the flag KbdInteractiveAuthentication - gssapi - config just the flag GSSAPIAuthentication - apparently internally calls out to Kerboros on some systems - kerboros? - KerberosAuthentication > Actually, why is "keyboard-interactive" a list? A container should be = fine and "submethods" should probably be a list instead. Perhaps, but I was thinking that by it being a list, augments could vary = by submethod. I dunno how important that might be hough.. > That is all the feedback I can provide for the = "keyboard-authentication" method. I could even suggest the exact YANG = changes if needed but I am missing the information about PAM support, if = nothing else. Someone else could add something in case I missed anything = and it would be great if you could find someone actually using the = "gssapi" methods to provide similar feedback, otherwise you will likely = have to rely on additional modules adding some augments, which is not an = ideal solution. Any suggestions you have would be good. =20 Honestly, I=E2=80=99m wondering if we should zero-out the = "client-authentication=E2=80=99 and thereby force any consuming = application to augment-in whatever config it thinks is needed=E2=80=A6thou= ghts about that? > [1] https://linux.die.net/man/5/sshd_config (search for = ChallengeResponseAuthentication) > [2] https://www.freebsd.org/cgi/man.cgi?login.conf(5)#end (section = AUTHENTICATION) > [3] https://api.libssh.org/stable/group__libssh__server.html (function = ssh_message_auth_interactive_request) > [4] = https://github.com/CESNET/libnetconf2/blob/master/src/session_server_ssh.c= #L809 >=20 >>>> The following regards the "tls-listen or tls-call-home or = sshcmn:ssh-x509-certs=E2=80=9D if-feature statement: >>>>>> But I wasn=E2=80=99t trying to fix your original issue. As = mentioned, there is a YANG-next issue and the best that consuming = modules can do is to 1) enable all the features defined in these modules = and 2) augment-in =E2=80=9Cuse=E2=80=9D-specific feature statements = where the groupings are used. >>>>>=20 >>>>> Okay, I suppose this can be done although it seems to me like a = minor deviation (the augment solution). What is the reason for not = having the module this way out-of-the-box? >>>>=20 >>>> It might be helpful to recall that this =E2=80=9Cif-feature=E2=80=9D = statement is in the netconf-client-server draft, and thus likely should = be discussed in another thread. That said, we=E2=80=99ve come so far = already, so why not a little more, right? ;) >>>>=20 >>>> So, do you have a proposal mind? >>>=20 >>> Right, we are getting OT, too bad :) I have attached a diff that = fixes my concerns and I think it also makes for a more intuitive tree = diagram. >>=20 >> Your diff points in a direction that looks good to me. I wish = you=E2=80=99d proposed it originally ;) >>=20 >> How does this commit look? = https://github.com/netconf-wg/netconf-client-server/commit/29523cfb2a8561c= 578fad7aaf36107bc7ecd5afb >=20 > Um, I do not think that works. It took me a while to understand but = based on the comment, you tried to add the "sshcmn:ssh-x509-certs" = if-feature to the "client-identity-mappings" container. To my knowledge, = what you actually did was augment-in no new nodes to the = "client-identity-mappings" container, but making 'all these no nodes' = conditional on an if-feature, none of which makes sense. The = "if-feature" in an augment relates to the "augment" itself, not to its = target, you can only add new nodes with an augment. Oh bother, the whole =E2=80=9Caugment=E2=80=9D vs. =E2=80=9Crefine=E2=80=9D= mixup again, here=E2=80=99s the fix: = https://github.com/netconf-wg/netconf-client-server/commit/f81d0c5b0a3361a= 4903b87c9777c33b1d143975c >> BTW, this introduces an issue as to if =E2=80=9Cclient-identity-mapping= s=E2=80=9D 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? >=20 > 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 =E2=80=9Cpublickey=E2=80=9D auth, = so a =E2=80=9Cusername=E2=80=9D is still being passed in the = SSH_MSG_USERAUTH_REQUEST message... K. From nobody Fri Apr 23 00:02:26 2021 Return-Path: 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 9E0803A0839 for ; Fri, 23 Apr 2021 00:02:24 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 g3Du8tat1-i7 for ; Fri, 23 Apr 2021 00:02:19 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee: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 E3F443A0835 for ; Fri, 23 Apr 2021 00:02:18 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 4F86360088; Fri, 23 Apr 2021 09:02:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619161334; bh=jITjscxtxUFYwG+Hb/1fYC1HT/oRSUNEd4P40lUD0ao=; h=From:In-Reply-To:Date:Cc:To:Subject; b=t3lWGFs560P+qt90DCpPb3VUWy4ZYpcd6gZfywISvQwzehEabLg7q+RMqVNYjGcbx 8UTDhx3u0KZE7sAQVs2VLxvNKtjIVhANHnQ3/MdKTuLLlqhDHvPSpVPQbbYrimsOA7 ZbnRcGjh14v0ARBLUaATrBCXg+Fl0D/djqldQwMU= From: =?utf-8?q?Michal_Va=C5=A1ko?= Content-Type: multipart/mixed; boundary="----=_=-_OpenGroupware_org_NGMime-18972-1619161334.293193-9------" In-Reply-To: <01000178fb076531-6b172846-f310-4c85-ac7f-33cdd699698c-000000@email.amazonses.com> X-Forward: 84.42.188.124 Date: Fri, 23 Apr 2021 09:02:14 +0200 Cc: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <4a1c-60827100-b1-56d88580@150796859> User-Agent: SOGoMail 5.1.0 Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 07:02:25 -0000 ------=_=-_OpenGroupware_org_NGMime-18972-1619161334.293193-9------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 16127 Hi Kent, > Hi Michal, > > >>>>> An improvement I can think of is to put all the authentication = methods in "users/user" in a mandatory choice. The authentication metho= ds would be one case, while something like "global-config" (empty leaf,= for example) would be the other. That should allow for maximum versati= lity when one could configure the 'global authentication methods', enab= le the "client-auth-config-supported" feature to configure the recogniz= ed users, but use the global authentication methods settings for some/a= ll the users (not having to configure each one separately). Because tha= t will probably be our use-case. > >>>> > >>>> Could you provide a tree diagram snippet that illustrates this? = Regarding your last sentence, I imagine that that might be many folks = use-case. That is, the actual user-auth might be somewhere else (e.g.,= PAM, LDAP, etc.); it might be rare thing that folks would want to conf= ig users inside the =E2=80=9Cssh-server-grouping=E2=80=9D. > >>> > >>> I wanted to, but quickly learned that I did not understand this Y= ANG part correctly. It seems every client authentication method has its= own feature AND a leaf or container in {grouping:ssh-server-grouping}/= client-authentication/supported-authentication-methods that marks suppo= rt for the authentication method, again. Why the redundancy? > >> > >> The "{grouping:ssh-server-grouping}/client-authentication/supporte= d-authentication-methods=E2=80=9D container is solely for enabling the = SSH-server know which authentication methods to present to the client d= uring the handshake. > >> > >> The "{grouping:ssh-server-grouping}/client-authentication/users=E2= =80=9D container is a locally-defined list of users and credentials tha= t can be used to authenticate them. > >> > >> In theory, the "supported-authentication-methods=E2=80=9D could be= derived as the union of the methods configured for each user, but at s= ome point the =E2=80=9Cca-certs=E2=80=9D and =E2=80=9Cee-certs=E2=80=9D= were pulled out of that container, and so that can=E2=80=99t be the ca= se anymore=E2=80=A6assuming it was ever a good idea in the first place.= .. > > > > I suppose I was not clear enough, the seeming redundancy is in all = the specific client-authentication features AND the "supported-authenti= cation-methods". You must both enable a feature and create the correspo= nding leaf/container to actually support the method. > > > > But it seems enabled feature marks something like a capability of t= he system to support the authentication method and the data whether you= actually want to advertise the method for new SSH clients. I am not s= ure this distinction is needed, though. > > The =E2=80=9Cfeature=E2=80=9D indicates if the server supports that c= onfiguration at all. For instance, there may be an SSH server that onl= y supports =E2=80=9Cpublickey" or only X509 certs. The feature gates w= hat can be configured, long before a handshake. > > > > It seems to me the "supported-authentication-methods" container can= be removed altogether and the advertised authentication methods will s= imply be all the configured ones for the user. > > The "supported-authentication-methods=E2=80=9D are to know what list = of auth-methods to present to the SSH client during the handshake. It = would be ideal if this list could be derived from either =E2=80=9Cfeatu= res=E2=80=9D and as the union of the methods configured for each user. > > Looking at RFC 4252, Section 5.1 (Responses to Authentication Request= s) says: > > If the server rejects the authentication request, it MUST respond > with the following: > > byte SSH=5FMSG=5FUSERAUTH=5FFAILURE > name-list authentications that can continue > boolean partial success > > The 'authentications that can continue' is a comma-separated name-= > list of authentication 'method name' values that may productively > continue the authentication dialog. > > It is RECOMMENDED that servers only include those 'method name' > values in the name-list that are actually useful. However, it is = not > illegal to include 'method name' values that cannot be used to > authenticate the user. > > Already successfully completed authentications SHOULD NOT be inclu= ded > in the name-list, unless they should be performed again for some > > > > And Section 5.2 (The "none" Authentication Request) says: > > A client may request a list of authentication 'method name' values= > that may continue by using the "none" authentication 'method name'= . > > If no authentication is needed for the user, the server MUST retur= n > SSH=5FMSG=5FUSERAUTH=5FSUCCESS. Otherwise, the server MUST return= > SSH=5FMSG=5FUSERAUTH=5FFAILURE and MAY return with it a list of me= thods > that may continue in its 'authentications that can continue' value= . > > > So my reading is that the list of auth methods SHOULD be user-specifi= c but MAY be (dare I say) feature-specific. In either case, it seems t= hat an explicit "supported-authentication-methods=E2=80=9D may be too m= uch. I=E2=80=99m tempted to remove it... Right, that is what I suggested, too. Based on the references it seems = returning user-specific supported-authentication list is the best thing= to do, anyway. > >>> Regarding the client authentication configuration, which is a sep= arate issue, I suppose the most generic solution would be to model it t= he same way certificates and some other things are. Meaning, to have a = separate container with a list of client-authentication configurations.= Then, every {grouping:ssh-server-grouping}/client-authentication/users= /user will have to reference one. That should allow support for all kin= ds of scenarios, including one where there is only a single client-auth= entication configuration and all the users reference it. > >> > >> This is where your providing a snippet of a tree diagram would be = helpful. Hopefully, with the above explanation, you're more able to do= that now=E2=80=A6? > > > > I am sorry, I have still not adjusted to the fact that the modules = now include all the configuration needed, with nothing being read from = the system. Having understood this, I think the current principle of pe= r-user configuration is fine, there is no other solution. > > I=E2=80=99m unsure if =E2=80=9Cnothing being read from the system=E2=80= =9D is accurate. Yes, this has been a thought, but I think it falls in= to two broad categories: > > 1) per-user credentials (e.g., passwords in /client-authentication/us= ers) > 2) user-independent credential authenticators > 2a) configured PKI issuers (e.g., =E2=80=9Cee-certs=E2=80=9D an= d =E2=80=9Cca-certs=E2=80=9D) > 2b) configured callout mechanisms (e.g., PAM, LDAP, Radius, etc= .) > > Some comments: > > - we do not yet have anything in the model representing (2b) > - (1) could always be viewed as something that should be provided b= y a (2b) Thanks for the information, good to know. > > But to fully configure the "keyboard-interactive" method, there is = some more information needed. I have looked at how libssh and OpenSSH s= shd(7) configure this method. > > > > Starting with sshd, it relies on login or PAM [1]. I do not have an= y experience with PAM so I do not know how exactly that is supported in= these YANG modules. But as for login, it seems to basically duplicate = the functionality of the "password" authentication [2]. That is my expe= rience as well but I do not know any more background for this. So, the = configuration would again be simply a "password" leaf. > > > > As for libssh, it went for a completely generic solution in which y= ou must specify the method name (which maps to the "submethod" would be= my guess), the instruction, and a list of challenge-response prompts [= 3]. We have implemented the simple password authentication this way [4]= , when the password is read from the system (the login functionality, a= ctually). Going with this full configuration, the instruction and a lis= t of challenge-response prompts (with echo configuration) should be add= ed to "{grouping:ssh-server-grouping}/client-authentication/users/keybo= ard-interactive/submethod=E2=80=9D. > > I very much agree with modeling after how other well-known servers ar= e configured. One thing for sure, per-user passwords, public keys, and= the like are NOT configured in sshd=5Fconfig (they=E2=80=99re in a per= -user directory, accessible via PAM, presumably). > > Per auth method: > > - hostbased: > - specifies all config via: > - HostKey, HostKeyAlgorithms, and HostbasedAuthentication > > - password: > - config just flags: PasswordAuthentication., PermitEmptyPasswo= rds > - but /etc/passwd typically used > > - publickey: > - in sshd=5Fconfig, a callout can be configured via AuthorizedK= eysCommand > - ...but ~/.ssh/authorized=5Fkeys typically used > > - keyboard-interactive > - config just the flag KbdInteractiveAuthentication > > - gssapi > - config just the flag GSSAPIAuthentication > - apparently internally calls out to Kerboros on some systems > > - kerboros? > - KerberosAuthentication One can always rely on the system itself if the feature "client-auth-co= nfig-supported" is kept disabled. But if enabled, all the information n= eeded to configure an authentication method should be in the YANG modul= e, right? It seems to me that is how it is now, for all the previous me= thods, I tried to suggest what can be done for the "keyboard-interactiv= e" method to be like that, too. > > Actually, why is "keyboard-interactive" a list? A container should = be fine and "submethods" should probably be a list instead. > > Perhaps, but I was thinking that by it being a list, augments could v= ary by submethod. I dunno how important that might be hough.. > > > > That is all the feedback I can provide for the "keyboard-authentica= tion" method. I could even suggest the exact YANG changes if needed but= I am missing the information about PAM support, if nothing else. Someo= ne else could add something in case I missed anything and it would be g= reat if you could find someone actually using the "gssapi" methods to p= rovide similar feedback, otherwise you will likely have to rely on addi= tional modules adding some augments, which is not an ideal solution. > > Any suggestions you have would be good. > > Honestly, I=E2=80=99m wondering if we should zero-out the "client-aut= hentication=E2=80=99 and thereby force any consuming application to aug= ment-in whatever config it thinks is needed=E2=80=A6thoughts about that= ? I think that could easily prevent interoperability and see no reason fo= r that. You got this far, would be a shame to give up now :) I have att= ached my changes that should allow to configure any "keyboard-interacti= ve" authentication. The information should all be there but the descrip= tions may be too brief. > > [1] https://linux.die.net/man/5/sshd=5Fconfig (search for Challenge= ResponseAuthentication) > > [2] https://www.freebsd.org/cgi/man.cgi?login.conf(5)#end (section = AUTHENTICATION) > > [3] https://api.libssh.org/stable/group=5F=5Flibssh=5F=5Fserver.htm= l (function ssh=5Fmessage=5Fauth=5Finteractive=5Frequest) > > [4] https://github.com/CESNET/libnetconf2/blob/master/src/session=5F= server=5Fssh.c#L809 > > > >>>> The following regards the "tls-listen or tls-call-home or sshcmn= :ssh-x509-certs=E2=80=9D if-feature statement: > >>>>>> But I wasn=E2=80=99t trying to fix your original issue. As me= ntioned, there is a YANG-next issue and the best that consuming modules= can do is to 1) enable all the features defined in these modules and 2= ) augment-in =E2=80=9Cuse=E2=80=9D-specific feature statements where th= e groupings are used. > >>>>> > >>>>> Okay, I suppose this can be done although it seems to me like a= minor deviation (the augment solution). What is the reason for not hav= ing the module this way out-of-the-box? > >>>> > >>>> It might be helpful to recall that this =E2=80=9Cif-feature=E2=80= =9D statement is in the netconf-client-server draft, and thus likely sh= ould be discussed in another thread. That said, we=E2=80=99ve come so = far already, so why not a little more, right? ;) > >>>> > >>>> So, do you have a proposal mind? > >>> > >>> Right, we are getting OT, too bad :) I have attached a diff that = fixes my concerns and I think it also makes for a more intuitive tree d= iagram. > >> > >> Your diff points in a direction that looks good to me. I wish yo= u=E2=80=99d proposed it originally ;) > >> > >> How does this commit look? https://github.com/netconf-wg/netconf-= client-server/commit/29523cfb2a8561c578fad7aaf36107bc7ecd5afb > > > > Um, I do not think that works. It took me a while to understand but= based on the comment, you tried to add the "sshcmn:ssh-x509-certs" if-= feature to the "client-identity-mappings" container. To my knowledge, w= hat you actually did was augment-in no new nodes to the "client-identit= y-mappings" container, but making 'all these no nodes' conditional on a= n if-feature, none of which makes sense. The "if-feature" in an augment= relates to the "augment" itself, not to its target, you can only add n= ew nodes with an augment. > > > Oh bother, the whole =E2=80=9Caugment=E2=80=9D vs. =E2=80=9Crefine=E2= =80=9D mixup again, here=E2=80=99s the fix: > > https://github.com/netconf-wg/netconf-client-server/commit/f81d0c5b0a= 3361a4903b87c9777c33b1d143975c Seems okay now. > >> BTW, this introduces an issue as to if =E2=80=9Cclient-identity-ma= ppings=E2=80=9D 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 scen= arios) 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 exp= erience, 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 t= he configuration of these methods. But that is not what is found in the= se YANG modules so I guess I am wrong. > > X.509-based auth *is* a variation of =E2=80=9Cpublickey=E2=80=9D auth= , so a =E2=80=9Cusername=E2=80=9D is still being passed in the SSH=5FMS= G=5FUSERAUTH=5FREQUEST message... Right, it takes me some time to absorb all the implications. So what ex= actly is the purpose of "client-identity-mappings" for SSH? A client mu= st 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 us= ername 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 NET= CONF clients deployed that use SSH for authentication but want to ident= ify users based on their certificates. Then there could be a single use= rname always used for SSH authentication but the NETCONF client would m= ap 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 con= figured in order for all the associated cert-to-name mappings to take e= ffect or simply all the configured mappings would always be tried and i= f some is successful, the resolved username will always be used for NET= CONF. I suppose a combination of this is also possible when the expecte= d SSH username may or may not be configured. Regards, Michal ------=_=-_OpenGroupware_org_NGMime-18972-1619161334.293193-9------ Content-Type: text/x-patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ietf-shh-server.yang.diff" Content-Length: 3609 NDM4YzQzOAo8ICAgICAgICAgICBsaXN0IGtleWJvYXJkLWludGVyYWN0aXZlIHsKLS0tCj4g ICAgICAgICAgIGNvbnRhaW5lciBrZXlib2FyZC1pbnRlcmFjdGl2ZSB7CjQ0MGM0NDAsNDQx CjwgICAgICAgICAgICAga2V5IHN1Ym1ldGhvZDsKLS0tCj4gICAgICAgICAgICAgcHJlc2Vu Y2UKPiAgICAgICAgICAgICAgICJJbmRpY2F0ZXMgdGhhdCB0aGUgJ2tleWJvYXJkLWludGVy YWN0aXZlJyBtZXRob2QgaXMgc3VwcG9ydGVkLiI7CjQ0Miw0NDdjNDQzLDQ0OQo8ICAgICAg ICAgICAgICAgIkluZGljYXRlcyB0aGF0IHRoZSBzZXJ2ZXIgY2FuIGF1dGhlbnRpY2F0ZSB0 aGlzCjwgICAgICAgICAgICAgICAgdXNlciB1c2luZyB0aGUgY29uZmlndXJlZCBzdWJtZXRo b2QuICBDb25zdW1pbmcKPCAgICAgICAgICAgICAgICBtb2R1bGVzIG1heSBhdWdtZW50LWlu IHN1Ym1ldGhvZC1zcGVjaWZpYwo8ICAgICAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24gYXMg bmVlZGVkLiI7CjwgICAgICAgICAgICAgbGVhZiBzdWJtZXRob2Qgewo8ICAgICAgICAgICAg ICAgdHlwZSBzdHJpbmc7Ci0tLQo+ICAgICAgICAgICAgICAgIkEgc2V0IG9mIHByZXNlbnRl ZCBjaGFsbGVuZ2UtZXhwZWN0ZWQgcmVzcG9uc2UgcGFpcnMKPiAgICAgICAgICAgICAgICBt YXkgYmUgdXNlZCBieSB0aGUgU1NIIHNlcnZlciB0byBhdXRoZW50aWNhdGUgdGhpcyB1c2Vy LiI7Cj4gICAgICAgICAgICAgbGVhZiBkZWZhdWx0LXN1Ym1ldGhvZCB7Cj4gICAgICAgICAg ICAgICBtYW5kYXRvcnkgdHJ1ZTsKPiAgICAgICAgICAgICAgIHR5cGUgbGVhZnJlZiB7Cj4g ICAgICAgICAgICAgICAgIHBhdGggInN1Ym1ldGhvZC9uYW1lIjsKPiAgICAgICAgICAgICAg IH0KNDQ5YzQ1MSw0NTgKPCAgICAgICAgICAgICAgICAgIlRoZSBuYW1lIG9mIHRoZSAnc3Vi bWV0aG9kJy4gIFZhbGlkIHZhbHVlcyBhcmUKLS0tCj4gICAgICAgICAgICAgICAgICJJZiB0 aGUgdXNlciBkb2VzIG5vdCByZXF1ZXN0IGFueSBzcGVjaWZpYwo+ICAgICAgICAgICAgICAg ICAgc3VibWV0aG9kLCB0aGlzIG9uZSB3aWxsIGJlIHVzZWQuIjsKPiAgICAgICAgICAgICB9 Cj4gICAgICAgICAgICAgbGlzdCBzdWJtZXRob2Qgewo+ICAgICAgICAgICAgICAga2V5ICJu YW1lIjsKPiAgICAgICAgICAgICAgIG1pbi1lbGVtZW50cyAxOwo+ICAgICAgICAgICAgICAg ZGVzY3JpcHRpb24KPiAgICAgICAgICAgICAgICAgIkFsbCB0aGUgc3VibWV0aG9kcyBzdXBw b3J0ZWQgZm9yIHRoZSB1c2VyLiBWYWxpZCB2YWx1ZXMgYXJlCjQ1MWE0NjEsNDk3Cj4gICAg ICAgICAgICAgICBsZWFmIG5hbWUgewo+ICAgICAgICAgICAgICAgICB0eXBlIHN0cmluZzsK PiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24KPiAgICAgICAgICAgICAgICAgICAiU3Vi bWV0aG9kIG5hbWUuIjsKPiAgICAgICAgICAgICAgIH0KPiAgICAgICAgICAgICAgIGxlYWYg aW5zdHJ1Y3Rpb24gewo+ICAgICAgICAgICAgICAgICB0eXBlIHN0cmluZzsKPiAgICAgICAg ICAgICAgICAgZGVzY3JpcHRpb24KPiAgICAgICAgICAgICAgICAgICAiVGhlIGluc3RydWN0 aW9uIHByZXNlbnRlZCB0byB0aGUgdXNlciBmb3IgdGhpcwo+ICAgICAgICAgICAgICAgICAg ICBzdWJtZXRob2QuIjsKPiAgICAgICAgICAgICAgIH0KPiAgICAgICAgICAgICAgIGxpc3Qg cHJvbXB0IHsKPiAgICAgICAgICAgICAgICAga2V5ICJjaGFsbGVuZ2UiOwo+ICAgICAgICAg ICAgICAgICBtaW4tZWxlbWVudHMgMTsKPiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24K PiAgICAgICAgICAgICAgICAgICAiTGlzdCBvZiBwcm9tcHRzIHByZXNlbnRlZCB0byB0aGUg dXNlciB0aGF0Cj4gICAgICAgICAgICAgICAgICAgIG11c3QgYmUgcGFzc2VkIGZvciBzdWNj ZXNzZnVsIGF1dGhlbnRpY2F0aW9uCj4gICAgICAgICAgICAgICAgICAgIG9mIHRoaXMgc3Vi bWV0aG9kLiI7Cj4gICAgICAgICAgICAgICAgIGxlYWYgY2hhbGxlbmdlIHsKPiAgICAgICAg ICAgICAgICAgICB0eXBlIHN0cmluZzsKPiAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlv bgo+ICAgICAgICAgICAgICAgICAgICAgIlRoZSBjaGFsbGVuZ2UgKHByb21wdCkgcHJlc2Vu dGVkIHRvIHRoZSB1c2VyLiI7Cj4gICAgICAgICAgICAgICAgIH0KPiAgICAgICAgICAgICAg ICAgbGVhZiByZXNwb25zZSB7Cj4gICAgICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7 Cj4gICAgICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7Cj4gICAgICAgICAgICAgICAgICAg ZGVzY3JpcHRpb24KPiAgICAgICAgICAgICAgICAgICAgICJUaGUgZXhwZWN0ZWQgcmVzcG9u c2UgdG8gdGhlIGNoYWxsZW5nZS4iOwo+ICAgICAgICAgICAgICAgICB9Cj4gICAgICAgICAg ICAgICAgIGxlYWYgZWNobyB7Cj4gICAgICAgICAgICAgICAgICAgdHlwZSBib29sZWFuOwo+ ICAgICAgICAgICAgICAgICAgIGRlZmF1bHQgdHJ1ZTsKPiAgICAgICAgICAgICAgICAgICBk ZXNjcmlwdGlvbgo+ICAgICAgICAgICAgICAgICAgICAgIldoZXRoZXIgdG8gZW5hYmxlIG9y IGRpc2FibGUgc2hlbGwgZWNobyBpbiBjYXNlCj4gICAgICAgICAgICAgICAgICAgICAgc29t ZSBzZW5zaXRpdmUgaW5mb3JtYXRpb24gaXMgcmVxdWVzdGVkLiI7Cj4gICAgICAgICAgICAg ICAgIH0KPiAgICAgICAgICAgICAgIH0K ------=_=-_OpenGroupware_org_NGMime-18972-1619161334.293193-9-------- From nobody Fri Apr 23 00:32:59 2021 Return-Path: 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 B6D4A3A0BBA for ; Fri, 23 Apr 2021 00:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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] 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 AzPMEijq6Iho for ; Fri, 23 Apr 2021 00:32:51 -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 12D573A0BB3 for ; Fri, 23 Apr 2021 00:32:51 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 37D3B60085; Fri, 23 Apr 2021 09:32:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619163168; bh=bn13yBLai6gFOrkm2VxlP4rEY0DcmPXHpr2inGgH2og=; h=From:In-Reply-To:Date:Cc:To:Subject; b=xz7uuJ+U8nlS+MlKqENCwNUlgEZjcPiSdV/cELsBq1WibYK4wKlwaE88f0TlBKc5o 5n/kACKrw7005e3GI4PW7ocVnfJOuZt8TrkSjmQpRF8vZYnNV1z8f2w9KtTNvFsRIx nCpKNmm0twNCkTyu4cqV9TBKg+P5pfcv4UsQ2huA= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <4a1c-60827100-b1-56d88580@150796859> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Fri, 23 Apr 2021 09:32:48 +0200 Cc: "Kent Watsen" , =?utf-8?q?netconf=40ietf.org?= To: =?utf-8?q?Michal_Va=C5=A1ko?= MIME-Version: 1.0 Message-ID: <7e2a-60827800-7-3739b980@174173102> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 07:32:57 -0000 Second time I forgot so I'd rather send it now so that I do not forget = again. It seems to me that "{grouping:ssh-server-grouping}/client-authe= ntication" contains really sensitive information so I would expect it t= o have "nacm:default-deny-all;". > Hi Kent, > > > Hi Michal, > > > > >>>>> An improvement I can think of is to put all the authenticatio= n methods in "users/user" in a mandatory choice. The authentication met= hods would be one case, while something like "global-config" (empty lea= f, for example) would be the other. That should allow for maximum versa= tility when one could configure the 'global authentication methods', en= able the "client-auth-config-supported" feature to configure the recogn= ized users, but use the global authentication methods settings for some= /all the users (not having to configure each one separately). Because t= hat will probably be our use-case. > > >>>> > > >>>> Could you provide a tree diagram snippet that illustrates this= ? Regarding your last sentence, I imagine that that might be many folk= s use-case. That is, the actual user-auth might be somewhere else (e.g= ., PAM, LDAP, etc.); it might be rare thing that folks would want to co= nfig users inside the =E2=80=9Cssh-server-grouping=E2=80=9D. > > >>> > > >>> I wanted to, but quickly learned that I did not understand this= YANG part correctly. It seems every client authentication method has i= ts own feature AND a leaf or container in {grouping:ssh-server-grouping= }/client-authentication/supported-authentication-methods that marks sup= port for the authentication method, again. Why the redundancy? > > >> > > >> The "{grouping:ssh-server-grouping}/client-authentication/suppor= ted-authentication-methods=E2=80=9D container is solely for enabling th= e SSH-server know which authentication methods to present to the client= during the handshake. > > >> > > >> The "{grouping:ssh-server-grouping}/client-authentication/users=E2= =80=9D container is a locally-defined list of users and credentials tha= t can be used to authenticate them. > > >> > > >> In theory, the "supported-authentication-methods=E2=80=9D could = be derived as the union of the methods configured for each user, but at= some point the =E2=80=9Cca-certs=E2=80=9D and =E2=80=9Cee-certs=E2=80=9D= were pulled out of that container, and so that can=E2=80=99t be the ca= se anymore=E2=80=A6assuming it was ever a good idea in the first place.= .. > > > > > > I suppose I was not clear enough, the seeming redundancy is in al= l the specific client-authentication features AND the "supported-authen= tication-methods". You must both enable a feature and create the corres= ponding leaf/container to actually support the method. > > > > > > But it seems enabled feature marks something like a capability of= the system to support the authentication method and the data whether y= ou actually want to advertise the method for new SSH clients. I am not= sure this distinction is needed, though. > > > > The =E2=80=9Cfeature=E2=80=9D indicates if the server supports that= configuration at all. For instance, there may be an SSH server that o= nly supports =E2=80=9Cpublickey" or only X509 certs. The feature gates= what can be configured, long before a handshake. > > > > > > > It seems to me the "supported-authentication-methods" container c= an be removed altogether and the advertised authentication methods will= simply be all the configured ones for the user. > > > > The "supported-authentication-methods=E2=80=9D are to know what lis= t of auth-methods to present to the SSH client during the handshake. I= t would be ideal if this list could be derived from either =E2=80=9Cfea= tures=E2=80=9D and as the union of the methods configured for each user= . > > > > Looking at RFC 4252, Section 5.1 (Responses to Authentication Reque= sts) says: > > > > If the server rejects the authentication request, it MUST respon= d > > with the following: > > > > byte SSH=5FMSG=5FUSERAUTH=5FFAILURE > > name-list authentications that can continue > > boolean partial success > > > > The 'authentications that can continue' is a comma-separated nam= e-> list of authentication 'method name' values that may productivel= y > > continue the authentication dialog. > > > > It is RECOMMENDED that servers only include those 'method name' > > values in the name-list that are actually useful. However, it i= s not > > illegal to include 'method name' values that cannot be used to > > authenticate the user. > > > > Already successfully completed authentications SHOULD NOT be inc= luded > > in the name-list, unless they should be performed again for some= > > > > > > > > And Section 5.2 (The "none" Authentication Request) says: > > > > A client may request a list of authentication 'method name' valu= es> that may continue by using the "none" authentication 'method nam= e'. > > > > If no authentication is needed for the user, the server MUST ret= urn > > SSH=5FMSG=5FUSERAUTH=5FSUCCESS. Otherwise, the server MUST retu= rn> SSH=5FMSG=5FUSERAUTH=5FFAILURE and MAY return with it a list of = methods > > that may continue in its 'authentications that can continue' val= ue. > > > > > > So my reading is that the list of auth methods SHOULD be user-speci= fic but MAY be (dare I say) feature-specific. In either case, it seems= that an explicit "supported-authentication-methods=E2=80=9D may be too= much. I=E2=80=99m tempted to remove it... > > Right, that is what I suggested, too. Based on the references it seem= s returning user-specific supported-authentication list is the best thi= ng to do, anyway. > > > >>> Regarding the client authentication configuration, which is a s= eparate issue, I suppose the most generic solution would be to model it= the same way certificates and some other things are. Meaning, to have = a separate container with a list of client-authentication configuration= s. Then, every {grouping:ssh-server-grouping}/client-authentication/use= rs/user will have to reference one. That should allow support for all k= inds of scenarios, including one where there is only a single client-au= thentication configuration and all the users reference it. > > >> > > >> This is where your providing a snippet of a tree diagram would b= e helpful. Hopefully, with the above explanation, you're more able to = do that now=E2=80=A6? > > > > > > I am sorry, I have still not adjusted to the fact that the module= s now include all the configuration needed, with nothing being read fro= m the system. Having understood this, I think the current principle of = per-user configuration is fine, there is no other solution. > > > > I=E2=80=99m unsure if =E2=80=9Cnothing being read from the system=E2= =80=9D is accurate. Yes, this has been a thought, but I think it falls= into two broad categories: > > > > 1) per-user credentials (e.g., passwords in /client-authentication/= users) > > 2) user-independent credential authenticators > > 2a) configured PKI issuers (e.g., =E2=80=9Cee-certs=E2=80=9D = and =E2=80=9Cca-certs=E2=80=9D) > > 2b) configured callout mechanisms (e.g., PAM, LDAP, Radius, e= tc.) > > > > Some comments: > > > > - we do not yet have anything in the model representing (2b) > > - (1) could always be viewed as something that should be provided= by a (2b) > > Thanks for the information, good to know. > > > > But to fully configure the "keyboard-interactive" method, there i= s some more information needed. I have looked at how libssh and OpenSSH= sshd(7) configure this method. > > > > > > Starting with sshd, it relies on login or PAM [1]. I do not have = any experience with PAM so I do not know how exactly that is supported = in these YANG modules. But as for login, it seems to basically duplicat= e the functionality of the "password" authentication [2]. That is my ex= perience as well but I do not know any more background for this. So, th= e configuration would again be simply a "password" leaf. > > > > > > As for libssh, it went for a completely generic solution in which= you must specify the method name (which maps to the "submethod" would = be my guess), the instruction, and a list of challenge-response prompts= [3]. We have implemented the simple password authentication this way [= 4], when the password is read from the system (the login functionality,= actually). Going with this full configuration, the instruction and a l= ist of challenge-response prompts (with echo configuration) should be a= dded to "{grouping:ssh-server-grouping}/client-authentication/users/key= board-interactive/submethod=E2=80=9D. > > > > I very much agree with modeling after how other well-known servers = are configured. One thing for sure, per-user passwords, public keys, a= nd the like are NOT configured in sshd=5Fconfig (they=E2=80=99re in a p= er-user directory, accessible via PAM, presumably). > > > > Per auth method: > > > > - hostbased: > > - specifies all config via: > > - HostKey, HostKeyAlgorithms, and HostbasedAuthentication= > > > > - password: > > - config just flags: PasswordAuthentication., PermitEmptyPass= words > > - but /etc/passwd typically used > > > > - publickey: > > - in sshd=5Fconfig, a callout can be configured via Authorize= dKeysCommand > > - ...but ~/.ssh/authorized=5Fkeys typically used > > > > - keyboard-interactive > > - config just the flag KbdInteractiveAuthentication > > > > - gssapi > > - config just the flag GSSAPIAuthentication > > - apparently internally calls out to Kerboros on some systems= > > > > - kerboros? > > - KerberosAuthentication > > One can always rely on the system itself if the feature "client-auth-= config-supported" is kept disabled. But if enabled, all the information= needed to configure an authentication method should be in the YANG mod= ule, right? It seems to me that is how it is now, for all the previous = methods, I tried to suggest what can be done for the "keyboard-interact= ive" method to be like that, too. > > > > Actually, why is "keyboard-interactive" a list? A container shoul= d be fine and "submethods" should probably be a list instead. > > > > Perhaps, but I was thinking that by it being a list, augments could= vary by submethod. I dunno how important that might be hough.. > > > > > > > That is all the feedback I can provide for the "keyboard-authenti= cation" method. I could even suggest the exact YANG changes if needed b= ut I am missing the information about PAM support, if nothing else. Som= eone else could add something in case I missed anything and it would be= great if you could find someone actually using the "gssapi" methods to= provide similar feedback, otherwise you will likely have to rely on ad= ditional modules adding some augments, which is not an ideal solution. > > > > Any suggestions you have would be good. > > > > Honestly, I=E2=80=99m wondering if we should zero-out the "client-a= uthentication=E2=80=99 and thereby force any consuming application to a= ugment-in whatever config it thinks is needed=E2=80=A6thoughts about th= at? > > I think that could easily prevent interoperability and see no reason = for that. You got this far, would be a shame to give up now :) I have a= ttached my changes that should allow to configure any "keyboard-interac= tive" authentication. The information should all be there but the descr= iptions may be too brief. > > > > [1] https://linux.die.net/man/5/sshd=5Fconfig (search for Challen= geResponseAuthentication) > > > [2] https://www.freebsd.org/cgi/man.cgi?login.conf(5)#end (sectio= n AUTHENTICATION) > > > [3] https://api.libssh.org/stable/group=5F=5Flibssh=5F=5Fserver.h= tml (function ssh=5Fmessage=5Fauth=5Finteractive=5Frequest) > > > [4] https://github.com/CESNET/libnetconf2/blob/master/src/session= =5Fserver=5Fssh.c#L809 > > > > > >>>> The following regards the "tls-listen or tls-call-home or sshc= mn:ssh-x509-certs=E2=80=9D if-feature statement: > > >>>>>> But I wasn=E2=80=99t trying to fix your original issue. As = mentioned, there is a YANG-next issue and the best that consuming modul= es can do is to 1) enable all the features defined in these modules and= 2) augment-in =E2=80=9Cuse=E2=80=9D-specific feature statements where = the groupings are used. > > >>>>> > > >>>>> Okay, I suppose this can be done although it seems to me like= a minor deviation (the augment solution). What is the reason for not h= aving the module this way out-of-the-box? > > >>>> > > >>>> It might be helpful to recall that this =E2=80=9Cif-feature=E2= =80=9D statement is in the netconf-client-server draft, and thus likely= should be discussed in another thread. That said, we=E2=80=99ve come = so far already, so why not a little more, right? ;) > > >>>> > > >>>> So, do you have a proposal mind? > > >>> > > >>> Right, we are getting OT, too bad :) I have attached a diff tha= t fixes my concerns and I think it also makes for a more intuitive tree= diagram. > > >> > > >> Your diff points in a direction that looks good to me. I wish = you=E2=80=99d proposed it originally ;) > > >> > > >> How does this commit look? https://github.com/netconf-wg/netcon= f-client-server/commit/29523cfb2a8561c578fad7aaf36107bc7ecd5afb > > > > > > Um, I do not think that works. It took me a while to understand b= ut based on the comment, you tried to add the "sshcmn:ssh-x509-certs" i= f-feature to the "client-identity-mappings" container. To my knowledge,= what you actually did was augment-in no new nodes to the "client-ident= ity-mappings" container, but making 'all these no nodes' conditional on= an if-feature, none of which makes sense. The "if-feature" in an augme= nt relates to the "augment" itself, not to its target, you can only add= new nodes with an augment. > > > > > > Oh bother, the whole =E2=80=9Caugment=E2=80=9D vs. =E2=80=9Crefine=E2= =80=9D mixup again, here=E2=80=99s the fix: > > > > https://github.com/netconf-wg/netconf-client-server/commit/f81d0c5b= 0a3361a4903b87c9777c33b1d143975c > > Seems okay now. > > > >> BTW, this introduces an issue as to if =E2=80=9Cclient-identity-= mappings=E2=80=9D are required for SSH when certs are used, or if the S= SH username that is built into the protocol (and used in al non-cert sc= enarios) should take precedence. Thoughts? > > > > > > I have never configured or used certificates for SSH authenticati= on so this is not a question that I can answer. But based on my other e= xperience, I would naively guess that it means you are using certificat= es instead of SSH keys, which seems to me is relevant for the "hostbase= d" and "publickey" authentication methods and would, in-effect, replace= the configuration of these methods. But that is not what is found in t= hese YANG modules so I guess I am wrong. > > > > X.509-based auth *is* a variation of =E2=80=9Cpublickey=E2=80=9D au= th, so a =E2=80=9Cusername=E2=80=9D is still being passed in the SSH=5F= MSG=5FUSERAUTH=5FREQUEST 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 c= an 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 mappin= g configuration. Am I missing something? > > Actually, maybe I can think of a scenario. Supposing there are some N= ETCONF clients deployed that use SSH for authentication but want to ide= ntify users based on their certificates. Then there could be a single u= sername always used for SSH authentication but the NETCONF client would= map the specific certificate to a NETCONF username. That would allow t= he server, for example, to still implement NACM but effectively identif= y 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 c= onfigured 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 N= ETCONF. I suppose a combination of this is also possible when the expec= ted SSH username may or may not be configured. > > Regards, > Michal From nobody Fri Apr 23 15:32:54 2021 Return-Path: <0100017900dd3b3b-d9ba3e7f-9f22-4fca-9060-da74b305fc4f-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 5C1BE3A122D for ; Fri, 23 Apr 2021 15:32:53 -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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 U68Su-UEM8ga for ; Fri, 23 Apr 2021 15:32:50 -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 B2D4D3A122B for ; Fri, 23 Apr 2021 15:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619217169; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=IHodjsNXBSDfMqND+5rRJ1APNrRbqAPW0333GMliFYk=; b=BsBdYB6la+AoYdbO0CvRCYhsmMFMG5m009lGEe22yy9cQ4bgG0eihnNKIsOwjRZc IYiiGIudbWQ1YtwBSldI24djX3ifjsmFp+pEpMDaLpGziuCwBDMhu310vlCGN+t83ui kPUkYq9JL6AOxUSpIiIVHTfoKnZ3ZtIEmlRFsksM= 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 In-Reply-To: <4a1c-60827100-b1-56d88580@150796859> Date: Fri, 23 Apr 2021 22:32:49 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017900dd3b3b-d9ba3e7f-9f22-4fca-9060-da74b305fc4f-000000@email.amazonses.com> References: <4a1c-60827100-b1-56d88580@150796859> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.23-54.240.8.83 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 22:32:53 -0000 Hi Michal, Thinning out resolved items below. Thanks, Kent >>> But to fully configure the "keyboard-interactive" method, there is = some more information needed. I have looked at how libssh and OpenSSH = sshd(7) configure this method. >>>=20 >>> Starting with sshd, it relies on login or PAM [1]. I do not have any = experience with PAM so I do not know how exactly that is supported in = these YANG modules. But as for login, it seems to basically duplicate = the functionality of the "password" authentication [2]. That is my = experience as well but I do not know any more background for this. So, = the configuration would again be simply a "password" leaf. >>>=20 >>> As for libssh, it went for a completely generic solution in which = you must specify the method name (which maps to the "submethod" would be = my guess), the instruction, and a list of challenge-response prompts = [3]. We have implemented the simple password authentication this way = [4], when the password is read from the system (the login functionality, = actually). Going with this full configuration, the instruction and a = list of challenge-response prompts (with echo configuration) should be = added to = "{grouping:ssh-server-grouping}/client-authentication/users/keyboard-inter= active/submethod=E2=80=9D. >>=20 >> I very much agree with modeling after how other well-known servers = are configured. One thing for sure, per-user passwords, public keys, = and the like are NOT configured in sshd_config (they=E2=80=99re in a = per-user directory, accessible via PAM, presumably). >>=20 >> Per auth method: >>=20 >> - hostbased: >> - specifies all config via: >> - HostKey, HostKeyAlgorithms, and HostbasedAuthentication >>=20 >> - password: >> - config just flags: PasswordAuthentication., = PermitEmptyPasswords >> - but /etc/passwd typically used >>=20 >> - publickey: >> - in sshd_config, a callout can be configured via = AuthorizedKeysCommand >> - ...but ~/.ssh/authorized_keys typically used >>=20 >> - keyboard-interactive >> - config just the flag KbdInteractiveAuthentication >>=20 >> - gssapi >> - config just the flag GSSAPIAuthentication >> - apparently internally calls out to Kerboros on some systems >>=20 >> - kerboros? >> - KerberosAuthentication >=20 > One can always rely on the system itself if the feature = "client-auth-config-supported" is kept disabled. True. > But if enabled, all the information needed to configure an = authentication method should be in the YANG module, right? Yes. > It seems to me that is how it is now, for all the previous methods, I = tried to suggest what can be done for the "keyboard-interactive" method = to be like that, too. Okay, thanks. >>> That is all the feedback I can provide for the = "keyboard-authentication" method. I could even suggest the exact YANG = changes if needed but I am missing the information about PAM support, if = nothing else. Someone else could add something in case I missed anything = and it would be great if you could find someone actually using the = "gssapi" methods to provide similar feedback, otherwise you will likely = have to rely on additional modules adding some augments, which is not an = ideal solution. >>=20 >> Any suggestions you have would be good. >>=20 >> Honestly, I=E2=80=99m wondering if we should zero-out the = "client-authentication=E2=80=99 and thereby force any consuming = application to augment-in whatever config it thinks is needed=E2=80=A6thou= ghts about that? >=20 > I think that could easily prevent interoperability and see no reason = for that. You got this far, would be a shame to give up now :) Okay. > I have attached my changes that should allow to configure any = "keyboard-interactive" authentication. The information should all be = there but the descriptions may be too brief. I=E2=80=99ve incorporated the changes here: = https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b= 25c0c4c518379accffcf0. Note that this commit also removed the = "supported-authentication-methods=E2=80=9D container. Questions: 1) would you like you be added as a =E2=80=9CContributor=E2=80=9D? 2) should either =E2=80=9Cinstruction=E2=80=9D or =E2=80=9Cchallenge=E2=80= =9D nodes be mandatory? 3) should =E2=80=9Cee-certs=E2=80=9D/=E2=80=9Cca-certs=E2=80=9D be = moved under the =E2=80=9Cuser=E2=80=9D node too? 4) is there a need to provide a similar =E2=80=9Ckeyboard-interactive=E2= =80=9D update for the ssh-client? On #3, this is likely mostly for me to resolve, but it seems to me that = *all* client-auth details should be under the =E2=80=9Cuser=E2=80=9D = 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 =E2=80=9Cproductive method = names=E2=80=9D to return to the client. Thoughts? Separately, for background, I mentioned before that X.509-cert auth is a = variation of the =E2=80=9Cpublickey=E2=80=9D authentication method. RFC = 4253, Section 6.6 clearly indicates this, as it consistently says = "certificate or public key=E2=80=9D, and RFC 6187, Section-2.1 likewise = supports this. So, we could push the whole =E2=80=9Chow to support = X.509 formatted keys=E2=80=9D into/under the =E2=80=9Cpublickey=E2=80=9D = 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. >>>> BTW, this introduces an issue as to if = =E2=80=9Cclient-identity-mappings=E2=80=9D 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? >>>=20 >>> 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. >>=20 >> X.509-based auth *is* a variation of =E2=80=9Cpublickey=E2=80=9D = auth, so a =E2=80=9Cusername=E2=80=9D is still being passed in the = SSH_MSG_USERAUTH_REQUEST message... >=20 > 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? >=20 > 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. >=20 > 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 = =E2=80=9Cuser name=E2=80=9D 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=E2=80=9D needed at all? 2) if =E2=80=9Cyes=E2=80=9D, then do they override the base =E2=80=9Cuse= r name=E2=80=9D value? For #1, I think you=E2=80=99re saying that flexibility is good and, for = #2, RFC 6187 seems to be saying that it=E2=80=99s a matter of local = policy. Agreed? K. From nobody Fri Apr 23 15:36:47 2021 Return-Path: <0100017900e0ce87-063b8731-0103-46f4-988a-126d9e715742-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 2DABA3A1264 for ; Fri, 23 Apr 2021 15:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 mCkcachJInr1 for ; Fri, 23 Apr 2021 15:36:45 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230B23A1263 for ; Fri, 23 Apr 2021 15:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619217403; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=SBO+M0CJnb8piKW3KgX7qGmC9DLsoTqNJcdwJaHJsqk=; b=JecX8ggKgwf41djDUVzUzhRbTP8u5skTENwiBO4yUq/hZjEQzOBMrF6aHCbjo25v vFDHwEGtrT5KKNNluLZJbOGzHr+bF055LuSk8yZ8x+MbkwcI6xhY/92fps99OxRoVxw lFa35DgNgYCYBsX51h/sBP2htJajivXIAyi8HW2c= 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 In-Reply-To: <7e2a-60827800-7-3739b980@174173102> Date: Fri, 23 Apr 2021 22:36:43 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017900e0ce87-063b8731-0103-46f4-988a-126d9e715742-000000@email.amazonses.com> References: <7e2a-60827800-7-3739b980@174173102> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.23-54.240.48.110 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 22:36:46 -0000 Hi Michal, > Second time I forgot so I'd rather send it now so that I do not forget = again. It seems to me that = "{grouping:ssh-server-grouping}/client-authentication" contains really = sensitive information so I would expect it to have = "nacm:default-deny-all;=E2=80=9D. It=E2=80=99s already =E2=80=9Cdefault-deny-write=E2=80=9D. I only use = =E2=80=9Cdefault-deny-all=E2=80=9D (to also prevent reads) for cleartext = passwords and private-keys. I=E2=80=99ll leave it is for now, pending = more discussion. K. From nobody Sun Apr 25 23:31:14 2021 Return-Path: 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 ; 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 ; 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 ; 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: =?utf-8?q?Michal_Va=C5=A1ko?= 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: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <10f7-60865e00-73-1b8071a0@204658236> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 06:31:13 -0000 Hi Kent, > I=E2=80=99ve incorporated the changes here: https://github.com/netcon= f-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0.= > > Note that this commit also removed the "supported-authentication-meth= ods=E2=80=9D container. Great, thanks. Connected to the separate NACM-related question, the mos= t common way of configuring the keyboard-interactive authentication is = to request the user password, which would have to be stored in clear-te= xt now. To cover it, you could replace the "response" leaf by a choice = with "answer" string leaf and "password" ianach:crypt-hash leaf, for ex= ample. And leave some other possible specific responses for augments. > Questions: > 1) would you like you be added as a =E2=80=9CContributor=E2=80=9D? That is up to you, I am fine either way. > 2) should either =E2=80=9Cinstruction=E2=80=9D or =E2=80=9Cchalleng= e=E2=80=9D nodes be mandatory? As for "instruction", I left it optional on purpose because it should n= ot be required for correct functioning of this authentication method. B= ut I do think it should be configured so it is up to you to decide. Reg= arding "challenge", what do you mean? It is the key of a list so it is = mandatory. > 3) should =E2=80=9Cee-certs=E2=80=9D/=E2=80=9Cca-certs=E2=80=9D be = moved under the =E2=80=9Cuser=E2=80=9D node too? > 4) is there a need to provide a similar =E2=80=9Ckeyboard-interacti= ve=E2=80=9D 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 usi= ng 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 wh= ether you want to add it into the modules or not. We support customizin= g the priority of each method so that there are no 'wasted' methods tha= t only increase the authentication attempts. It seems that this is prev= ented in the SSH client module by all the "if-feature" on the individua= l 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 met= hods, in order, because you probably do not want to be bothered with th= e "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 th= at *all* client-auth details should be under the =E2=80=9Cuser=E2=80=9D= 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 =E2=80=9Cproductive method name= s=E2=80=9D to return to the client. Thoughts? > > Separately, for background, I mentioned before that X.509-cert auth i= s a variation of the =E2=80=9Cpublickey=E2=80=9D authentication method.= RFC 4253, Section 6.6 clearly indicates this, as it consistently says= "certificate or public key=E2=80=9D, and RFC 6187, Section-2.1 likewis= e supports this. So, we could push the whole =E2=80=9Chow to support X= .509 formatted keys=E2=80=9D into/under the =E2=80=9Cpublickey=E2=80=9D= umbrella. That said, it is way more natural for administrators to co= nfigure certs in their normal form then in the ssh-publickey form, henc= e 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 fi= ne the way it is but I do agree with your points and see no problems wi= th the change you proposed, either way seems fine. > >>>> BTW, this introduces an issue as to if =E2=80=9Cclient-identity-= mappings=E2=80=9D are required for SSH when certs are used, or if the S= SH username that is built into the protocol (and used in al non-cert sc= enarios) should take precedence. Thoughts? > >>> > >>> I have never configured or used certificates for SSH authenticati= on so this is not a question that I can answer. But based on my other e= xperience, I would naively guess that it means you are using certificat= es instead of SSH keys, which seems to me is relevant for the "hostbase= d" and "publickey" authentication methods and would, in-effect, replace= the configuration of these methods. But that is not what is found in t= hese YANG modules so I guess I am wrong. > >> > >> X.509-based auth *is* a variation of =E2=80=9Cpublickey=E2=80=9D a= uth, so a =E2=80=9Cusername=E2=80=9D is still being passed in the SSH=5F= MSG=5FUSERAUTH=5FREQUEST message... > > > > Right, it takes me some time to absorb all the implications. So wha= t exactly is the purpose of "client-identity-mappings" for SSH? A clien= t 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 sessio= n username based on the presented certificate and the cert-to-name mapp= ing 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 i= dentify users based on their certificates. Then there could be a single= username always used for SSH authentication but the NETCONF client wou= ld map the specific certificate to a NETCONF username. That would allow= the server, for example, to still implement NACM but effectively ident= ify users only based on their certificates. > > > > In this case your original question makes sense to me and I would s= ee 2 solutions. Either there would have to be the expected SSH username= configured in order for all the associated cert-to-name mappings to ta= ke effect or simply all the configured mappings would always be tried a= nd if some is successful, the resolved username will always be used for= NETCONF. I suppose a combination of this is also possible when the exp= ected 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. x509c= 2n:cert-to-name) may be needed while ignoring the fact that the =E2=80=9C= user name=E2=80=9D is already being passed in the base SSH=5FMSG=5FUSER= AUTH=5FREQUEST message. > > Popping this discussion back up to YANG models, ietf-netconf-server c= urrent 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=E2=80=9D needed at all? > 2) if =E2=80=9Cyes=E2=80=9D, then do they override the base =E2=80=9C= user name=E2=80=9D value? > > For #1, I think you=E2=80=99re saying that flexibility is good and, f= or #2, RFC 6187 seems to be saying that it=E2=80=99s a matter of local = policy. Agreed? For #1 I came up with a possible scenario when the "client-identity-map= pings" 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 an= yone else) are not able to come up with any other, I think these mappin= gs are not needed. Just a note, we do not and not plan to support the s= cenario. As for #2, I think I have suggested a way to allow configuring it eithe= r way so that the 'local policy' can be directly configured. And that w= ould probably be the best solution. Regards, Michal From nobody Mon Apr 26 10:06:53 2021 Return-Path: <010001790f25d43d-07a7c720-cb0c-494d-846b-91537afb94e9-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 160523A2926 for ; Mon, 26 Apr 2021 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 3ZarWoc_V9_R for ; Mon, 26 Apr 2021 10:06:49 -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 8FFD03A2923 for ; Mon, 26 Apr 2021 10:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619456808; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=GMYMVEaOGHH40jNwUmNQZ8K/3b2i1bSJ+LwXZj514wk=; b=Ipo6F0z126q5EXxgCzv+0P2ZR24pT97FEn09DWuYZvqHQOg+3ahZpDMqQda2x0IS vzSbG9dOj0e/AQFEU556dpPDLsl22KqoD6QSeP+w2f2dmbIZrSFlryg+nVv+NQIkQb3 Y2H2otlDkug+7Iu3hS/t+t9fud3KP6wZWFiX1Ecc= From: Kent Watsen Message-ID: <010001790f25d43d-07a7c720-cb0c-494d-846b-91537afb94e9-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5668201D-E06B-404B-B273-87A899EA492B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 26 Apr 2021 17:06:48 +0000 In-Reply-To: <10f7-60865e00-73-1b8071a0@204658236> Cc: "netconf@ietf.org" To: =?utf-8?Q?Michal_Va=C5=A1ko?= References: <10f7-60865e00-73-1b8071a0@204658236> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.26-54.240.8.83 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 17:06:52 -0000 --Apple-Mail=_5668201D-E06B-404B-B273-87A899EA492B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michal, >> I=E2=80=99ve incorporated the changes here: = https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b= 25c0c4c518379accffcf0. >>=20 >> Note that this commit also removed the = "supported-authentication-methods=E2=80=9D container. >=20 > 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. I don=E2=80=99t doubt you, but already SSH (* see below) allows for a = multiplicity of authentication methods so, e.g., =E2=80=9Cpublickey = password keyboard-interactive=E2=80=9D would mean that the client must = first pass =E2=80=9Cpublickey=E2=80=9D, then =E2=80=9Cpassword=E2=80=9D, = and finally =E2=80=9Ckeyboard-interactive=E2=80=9D. My point is that, = if a password is to be asked for, wouldn=E2=80=99t the =E2=80=9Cpassword=E2= =80=9D method be preferably used, and hence the existing = "ianach:crypt-hash=E2=80=9D protection suffice? =20 That said, I=E2=80=99m not against converting the =E2=80=9Cleaf=E2=80=9D = to a =E2=80=9Cchoice with a single =E2=80=98cleartext=E2=80=99 leaf=E2=80=9D= case if you think it=E2=80=99s better... * 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=E2=80=99t see a direct correlation = to =E2=80=9CAuthenticationMethods=E2=80=9D, unless you think = =E2=80=9Ckeyboard-interactive=E2=80=9D is it, but that doesn=E2=80=99t = follow from the manpage snippet above. >=20 >> Questions: >> 1) would you like you be added as a =E2=80=9CContributor=E2=80=9D? >=20 > That is up to you, I am fine either way. Added. >> 3) should =E2=80=9Cee-certs=E2=80=9D/=E2=80=9Cca-certs=E2=80=9D be = moved under the =E2=80=9Cuser=E2=80=9D node too? >> 4) is there a need to provide a similar =E2=80=9Ckeyboard-interactive=E2= =80=9D update for the ssh-client? >=20 > 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. In ietf.-ssh-client: should "leaf-list submethods=E2=80=9D or "leaf-list = oids=E2=80=9D be ordered-by user? RELATED: In iets-ssh-server: should any of =E2=80=9Clist submethod, = =E2=80=9Clist prompt=E2=80=9D, or "list gssapi-with-mic=E2=80=9D be = ordered-by user? > 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. The ssh_config manage has: PreferredAuthentications 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 We could support this either by: 1) wrap everything inside an =E2=80=9Cordered-by user=E2=80=9D list 2) define a =E2=80=9CPreferredAuthentications=E2=80=9D like variable, to = provide an external ordering Thoughts? >> On #3, this is likely mostly for me to resolve, but it seems to me = that *all* client-auth details should be under the =E2=80=9Cuser=E2=80=9D = 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 =E2=80=9Cproductive method = names=E2=80=9D to return to the client. Thoughts? >>=20 >> Separately, for background, I mentioned before that X.509-cert auth = is a variation of the =E2=80=9Cpublickey=E2=80=9D authentication method. = RFC 4253, Section 6.6 clearly indicates this, as it consistently says = "certificate or public key=E2=80=9D, and RFC 6187, Section-2.1 likewise = supports this. So, we could push the whole =E2=80=9Chow to support = X.509 formatted keys=E2=80=9D into/under the =E2=80=9Cpublickey=E2=80=9D = 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. >=20 > 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. If in your first question you mean an =E2=80=9CX.509-based publickey=E2=80= =9D, then yes, but... - if auth happens via an "ee-cert=E2=80=9D, the ee-cert for each user = needs to be configured, but it=E2=80=99s open as to if each user points = to a specific ee-cert or if all users point to a bag of ee-certs. - if auth happens via =E2=80=9Cca-cert=E2=80=9D, the same statements = apply, but there is even less affinity, as typically a CA issues many = EEs. >>>>>> BTW, this introduces an issue as to if = =E2=80=9Cclient-identity-mappings=E2=80=9D 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? >>>>>=20 >>>>> 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. >>>>=20 >>>> X.509-based auth *is* a variation of =E2=80=9Cpublickey=E2=80=9D = auth, so a =E2=80=9Cusername=E2=80=9D is still being passed in the = SSH_MSG_USERAUTH_REQUEST message... >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >>=20 >> Digging into RFC 6187 again, I find this jewel: >>=20 >> 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. >>=20 >> 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 = =E2=80=9Cuser name=E2=80=9D is already being passed in the base = SSH_MSG_USERAUTH_REQUEST message. >>=20 >> Popping this discussion back up to YANG models, ietf-netconf-server = current has this snippet: >>=20 >> 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? >> } >>=20 >> The questions are: >>=20 >> 1) are "client-identity-mappings=E2=80=9D needed at all? >> 2) if =E2=80=9Cyes=E2=80=9D, then do they override the base =E2=80=9Cu= ser name=E2=80=9D value? >>=20 >> For #1, I think you=E2=80=99re saying that flexibility is good and, = for #2, RFC 6187 seems to be saying that it=E2=80=99s a matter of local = policy. Agreed? >=20 > 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. Ack, and we shouldn't support a low-probability use-case. > 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. I think what you are saying is: 1) if a cert-to-name mapping is NOT found, then fallback to the = SSH-level username 2) if a cert-to-name mapping IS found, then it SHOULD override the = SSH-level username. Correct? K. --Apple-Mail=_5668201D-E06B-404B-B273-87A899EA492B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Michal,



I=E2=80=99ve incorporated the changes here: https://github.com/netconf-wg/ssh-client-server/commit/c434d249= baeab8f850b25c0c4c518379accffcf0.

Note that this commit also = removed the "supported-authentication-methods=E2=80=9D 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.

I = don=E2=80=99t doubt you, but already SSH (* see below) allows for a = multiplicity of authentication methods so, e.g., =E2=80=9Cpublickey = password keyboard-interactive=E2=80=9D would mean that the client must = first pass =E2=80=9Cpublickey=E2=80=9D, then =E2=80=9Cpassword=E2=80=9D, = and finally =E2=80=9Ckeyboard-interactive=E2=80=9D.  My point is = that, if a password is to be asked for, wouldn=E2=80=99t the = =E2=80=9Cpassword=E2=80=9D method be preferably used, and hence the = existing "ianach:crypt-hash=E2=80=9D protection suffice? =  

That said, I=E2=80=99m not = against converting the =E2=80=9Cleaf=E2=80=9D to a =E2=80=9Cchoice with = a single =E2=80=98cleartext=E2=80=99 leaf=E2=80=9D case if you think = it=E2=80=99s better...

* 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=E2=80=99t see a direct correlation to = =E2=80=9CAuthenticationMethods=E2=80=9D, unless you think = =E2=80=9Ckeyboard-interactive=E2=80=9D is it, but that doesn=E2=80=99t = follow from the manpage snippet above.







Questions:
 1) would you like you be = added as a =E2=80=9CContributor=E2=80=9D?

That is up to you, I am fine either way.

Added.



=  3) should =E2=80=9Cee-certs=E2=80=9D/=E2=80=9Cca-certs=E2=80=9D be = moved under the =E2=80=9Cuser=E2=80=9D node too?
 4) = is there a need to provide a similar =E2=80=9Ckeyboard-interactive=E2=80=9D= 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.


In = ietf.-ssh-client: should "leaf-list submethods=E2=80=9D or = "leaf-list oids=E2=80=9D be ordered-by user?

RELATED: =  In iets-ssh-server: should any of =E2=80=9Clist submethod, =E2=80=9C= list prompt=E2=80=9D, or "list gssapi-with-mic=E2=80=9D be = ordered-by user?


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.

The = ssh_config manage has:

    =  PreferredAuthentications
    =          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

We could support this either by:

1) wrap everything inside an =E2=80=9Cordered-by = user=E2=80=9D list

2) define a = =E2=80=9CPreferredAuthentications=E2=80=9D like = variable, to provide an external ordering

Thoughts?



On #3, = this is likely mostly for me to resolve, but it seems to me that *all* = client-auth details should be under the =E2=80=9Cuser=E2=80=9D 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 =E2=80=9Cproductive method = names=E2=80=9D to return to the client.  Thoughts?

Separately, for background, I mentioned before that = X.509-cert auth is a variation of the =E2=80=9Cpublickey=E2=80=9D = authentication method.  RFC 4253, Section 6.6 clearly indicates = this, as it consistently says "certificate or public key=E2=80=9D, and = RFC 6187, Section-2.1 likewise supports this.  So, we could push = the whole =E2=80=9Chow to support X.509 formatted keys=E2=80=9D = into/under the =E2=80=9Cpublickey=E2=80=9D 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.


If in your first = question you mean an =E2=80=9CX.509-based publickey=E2=80=9D, then yes, = but...

- if auth happens via an = "ee-cert=E2=80=9D, the ee-cert for each user needs to be configured, but = it=E2=80=99s open as to if each user points to a specific ee-cert or if = all users point to a bag of ee-certs.

- if auth happens via =E2=80=9Cca-cert=E2=80=9D, = the same statements apply, but there is even less affinity, as typically = a CA issues many EEs.



BTW, this introduces an issue as to if = =E2=80=9Cclient-identity-mappings=E2=80=9D 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 =E2=80=9Cpublickey=E2=80=9D auth, so a =E2=80=9Cusername=E2=80= =9D 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 =E2=80=9Cuser name=E2=80=9D = 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 {
=            descript= ion
=             &n= bsp;"A wrapper around the NETCONF server parameters
=             &n= bsp; to avoid name collisions.";
=            uses = ncs:netconf-server-grouping {
=             &n= bsp;refine "client-identity-mappings" {
=             &n= bsp;  if-feature "sshcmn:ssh-x509-certs";
=             &n= bsp;  description
=             &n= bsp;    "Augments in an 'if-feature' statement
=             &n= bsp;     ensuring the = 'client-identity-mappings'
=             &n= bsp;     descendent is enabled only when SSH
=             &n= bsp;     supports X.509 certificates.";
=             &n= bsp;} // FIXME: does an X.509-derived identity
=            } =   //        override SSH = username?
=          }

The questions are:

 1) are = "client-identity-mappings=E2=80=9D needed at all?
=  2) if =E2=80=9Cyes=E2=80=9D, then do they override the base = =E2=80=9Cuser name=E2=80=9D value?

For #1, = I think you=E2=80=99re saying that flexibility is good and, for #2, RFC = 6187 seems to be saying that it=E2=80=99s 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.

Ack, and = we shouldn't support a low-probability use-case.


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.

I think what you are saying is:

1) if a cert-to-name mapping is NOT found, then = fallback to the SSH-level username

2) = if a cert-to-name mapping IS found, then it SHOULD override the = SSH-level username.

Correct?


K.





= --Apple-Mail=_5668201D-E06B-404B-B273-87A899EA492B-- From nobody Mon Apr 26 10:21:54 2021 Return-Path: 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 60B8D3A29AF for ; Mon, 26 Apr 2021 10:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 RrBogbN7c-Oa for ; Mon, 26 Apr 2021 10:21:47 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80085.outbound.protection.outlook.com [40.107.8.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865A13A29B3 for ; Mon, 26 Apr 2021 10:21:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YFuJGXeW6Sw4+UgqWAFMT0O4C6SXRN9gonyJPl8nZNnQtuImkARikLMYpkXRURpdZAdVn1qWiGwoeG8SqLpvvDDA+bYIGRuzsLmKkFWE2VIDQP1bwTIvrP5k/DUOjo7vB2WunmglrkWPBI54Aypnovo0ienlvUmTI2SEa2cGL8XXhpGMzq/IEDK1rH2tvA5Cy8GW75XoikMnyEzmQOtT0xDvZMJsfobv5BzBaAyDt9XWin0I2ava5O5UQ7d7wHszJHGnd5e0sQ1OXpW6KRHUWLeVmINSNpHmbstR/9Lc8d6HmQ26avQ7cvduKg6x4u9HmuObesDL55FWF+IrtmGw0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FFyfgHzzvyT1aSfAxhoLnSBpBsFAzppvu4h8/zhJ7Ts=; b=A9zp3TIR52EKJKfXyZoLkIKCy5CZkKTwkUim0LIOO/2Aspvi9X4HzFkdkKXx0SBPhz9xwkG1LpEB6DNLRltwTCGcBpsDjEargIzyEu1GGxbHBSN8xIcK0PqAmxCAeVtpBCsge4Bw489H+Gh6c3b9Uxm6an09BKKwKtsCpKNXLXy7eAUa6ZwfafctwTJRj8SBus+8jclB0YPoWnXclaWJwrCNU0Y2xySHab0Xn6sJPGd1VqSIIC/QovAffOwZ0/cqyD1n52z0+rfIUxVyuKsPavqenZQvHo54IXKaWb0VOiroxNEMO3u/XDM7goPlPZAQJ6TYgX+/eJrry6zzaqsS1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FFyfgHzzvyT1aSfAxhoLnSBpBsFAzppvu4h8/zhJ7Ts=; b=QmY/Hl2hiZy6QvuPktQPsPorsRf12b7+pPcxSnkYzTgSDkerVg/7hIFg0Qhex6XL7G5ROslB4qqYA25eDebHgrWKO8hnieCXqJ0028tp/PmtIl/Xufg/A4bVcbq9EnljS93kdEs4fp5pphRirAgGRUAPsVPCyBnf/k+XzDLl3tk= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0674.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.22; Mon, 26 Apr 2021 17:21:45 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4065.027; Mon, 26 Apr 2021 17:21:45 +0000 Date: Mon, 26 Apr 2021 19:21:43 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: "netconf@ietf.org" Message-ID: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <10f7-60865e00-73-1b8071a0@204658236> <010001790f25d43d-07a7c720-cb0c-494d-846b-91537afb94e9-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <010001790f25d43d-07a7c720-cb0c-494d-846b-91537afb94e9-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR10CA0101.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::18) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR10CA0101.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.20 via Frontend Transport; Mon, 26 Apr 2021 17:21:44 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2c808367-485d-4ab7-85b5-08d908d7c3f2 X-MS-TrafficTypeDiagnostic: AM0P190MB0674: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kq5hEG5n349ckIOwkmKPMLMYmVlOdjXYO9iDktDw18CmKdcDjEDE1dUyGe4vcP2/UK04qHFDNdrZaLZPSOLXqpUPszOHeLOKxI+hmmCLKMCPP3YZcG01piDWFSLdI3bqb2WUqHQ8NA58Ite+X00CRvUXQWYTn/KWu4QW/s0Ym7hgGziEMpDZnXEegMJ2A/doqAcrKa5NwXd/rO/CvxSiPoAVDhhlf1vfn69RDNcjcbdrtTGWy2EkeWUaJVR8e7shwWBUeCCHWU5A+r83uWJlKaUgo2rPc7Wlunv77ToFMalFjjeBWTai1f8v9WcEZnM1/UmmHci1wPUU3oDCUPvdxOn3PDWPAxdGrKvDUsCndn5P32hEX+UyKehLClZMbko12NSs5Adg6ykCz/x+O+l70nlDLlTyePnR5V/m2Wuyvg5F8/+9m7Ut2NT8dwhwWErrLHhsIfy90zJvx7rgRixTYDK7zpjm1FGOlRFuzwRM+VjZtoPFv4nY4JI4LDqgqMPvRWyMYJpbZqTC9RrLWLhKsfuT90ZGjIFnWd20ljMUFy9i0IGFFW1+2TNEwsiK0RtsL1Fcaesahyay/9jpunL+KhXmE4pBTtTFjOXPUgLB0Zux1DKKWkXSMveauYqWShAW0aAb8aCVCacXIgLcsthI1i02Ze+w+pexvo5k+JOr8AN2YQet85tdYKWqvG1yNLeg3DyNnhwm/h1M24txykbpa6mVRy0EhMWnKLhBqJwRNeI= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(376002)(136003)(39840400004)(396003)(366004)(6486002)(8676002)(38350700002)(5660300002)(1076003)(66476007)(786003)(6496006)(38100700002)(52116002)(4326008)(316002)(86362001)(956004)(8936002)(186003)(16526019)(3450700001)(2906002)(83380400001)(478600001)(66556008)(66946007)(26005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Q2c5Uk5TODhxR09IV2w3cXFsWTVuczVyRHBHRTNYNUtlc21MMEdoWnFTQ3FH?= =?utf-8?B?QVJZaG9nd0F1RFp2VEhDbUFvNXZzMmtrczZmV3ZkcW01VWVwcWhaZXRseVU0?= =?utf-8?B?cG8wcE9wTG9OeGNqNm9NaFRMbmQySGdpVEVtQWdCVmRNOEdJYTV2cmVEZXdM?= =?utf-8?B?K25EUHkxWDFnRVJZWjV4RHozVUpVT0xydDMrZmdtRGk2aVhlWlFTdXJGUFlq?= =?utf-8?B?bGpISXF4QWZFWGdNdnFod0FJaTJNV21sSXEwSnQzV2ZCVUdNN2xrb2lNcWJr?= =?utf-8?B?cldCS0ZnSzc2dmVoYTVqZzM4Kys4bks4WkNVb0QvUVE1Qmw5Qzd4enlBazFD?= =?utf-8?B?RWJaL1o5N1ZmOHdMSTNyVjBVNnhhSVVxR001S1RlWUl4UnZlQ1Vjc1VpbDVZ?= =?utf-8?B?YXkvcHQwMkdiazU4M0Zlcjg4YmdzakFXM2t4aVFDMFFPdDg2VmlOMlpKNzV0?= =?utf-8?B?T3pNd2hUckN2dzUwaWEvcjJZZVk3ZXYzeUlYemMwdzE0V243VGtPSzJWakJs?= =?utf-8?B?TDNFTWQ2UVJVVDVzQkNiMkVtZHEzN1RCNzdtZUpVeHhYRWMwRmRpWGNxVFly?= =?utf-8?B?QUlReVhlenhGcXlwQUpHbXUvNVRRMlptOVdaT3N0L0x6ZG9jL1FJd0dPR2tZ?= =?utf-8?B?c2hobkFpK1V6a3JUMEVOVTk2YzhBRXpnY09QRHZDaXFERGlLaWZvRHh4L3ly?= =?utf-8?B?T3MxaVM3TEt3dko0MFdrM2F0YXNLUWxrTCt5VzJmOW1Ha2lJYkhVdmltQ1NX?= =?utf-8?B?N3ErdUZTZzVDRndIY2pXNHJDaWwwTVFnUkR0LzNCRGlvUnhHWHIwOUZFRjkw?= =?utf-8?B?L1hMam5XMVBGeGdjcXpBYUp5SnJoTElENURRY0E3YUdpbnpucWlnSzk2MEtS?= =?utf-8?B?dXA0MjBUMGdvV1J3V2NQZ0dTdi9xb1ZzWDZzUHR3TCt0R0EvNitTeUZ2TU9j?= =?utf-8?B?TUFYa2xzcDBBMkpHQ1FxQ1dPTHRNY3NMU3RqZll6VjM1OGN1T2Vpa2xwZ0NW?= =?utf-8?B?SDRhd1JnUGtqd0lHWlVNaTlNd3BCcUFURWduSnkwTVRXM3pDY1N4VkxkemUx?= =?utf-8?B?RjBWdGlTQTJyeG1td0JDVVc1Yy9OYit4S09oZUNiUFU3dGxSZXlLNGs1Vk9Q?= =?utf-8?B?UHZyekNhSmQ2eXV5Mm0vMkRhWEpxZUljRlFRWWRON0tSUXVuMHdVMEZJZ3Ax?= =?utf-8?B?dFJ4SFZ0NEJiazJqKzllYXRBTFF5b1ZPUDFaV0N0N054N3hwbjBwOGxtOGxE?= =?utf-8?B?ckRBOEFUdjU0OW9mTS9qWkk4MHE0MWlSc1N1OGxtc280RTJYa0oyUC9QYzFR?= =?utf-8?B?bktuV0FtaTAzblg1NjJmWWgyK25ocXFQMXp1b0lTNTZ5dEwvNGowTG16LzdY?= =?utf-8?B?ZGMxUThDY29EQ05jZnNCa0JVWEdNK0lwbjN2SHVzcHpFS0c0UFBrQWJ3UG45?= =?utf-8?B?VUx1TDEraEpRVHNsVzN2S2pkd29nZkVaWS9hT1NXTmZTd3VDeXp3ZTI0bFFN?= =?utf-8?B?L0FTc2pJcXQ2cXRaR3lVTFZnRWswWk9wN1Z3SU9ITGFORWY1akFrSFdJd0VZ?= =?utf-8?B?M2JDUFlDUnZPV0RmRFljdU5MVHltSEEzTzU3SmQ4ajdUOEVMOERYbk9YV2lE?= =?utf-8?B?MVUxd21BTDRiNzNKc21uVUJFbGZaelIwMTZac3BTempVRVlqNnJva214SHQ3?= =?utf-8?B?NmRBSWhiNGl5dlV5Tnk1Wk40cUdQMmhwamtGdzJJcFZQNFhXdTE3WTRONnFE?= =?utf-8?Q?ZbNS2+D4w6AQA5TAPYFn2ixImDKJTmCgwfoblf2?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 2c808367-485d-4ab7-85b5-08d908d7c3f2 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2021 17:21:44.9073 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: eAKuo75ypXKE6LSxi9SLWcxwRTBrWbWSQULy3EdKfxVeUKXfnryhdt3wvwA3iy5yoq/PE7PlvbVJtnZvg//LR2sGuO7zzp5YhQi4RW/0VLI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0674 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 17:21:52 -0000 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 From nobody Mon Apr 26 23:54:12 2021 Return-Path: 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 C3B463A12B6 for ; Mon, 26 Apr 2021 23:54:09 -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 fQADTCGHKAxy for ; Mon, 26 Apr 2021 23:54:05 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee: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 CA5283A12B5 for ; Mon, 26 Apr 2021 23:54:04 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 4B38A60084; Tue, 27 Apr 2021 08:54:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619506440; bh=1JAmm54a0mOejaCBED5hWtBx05AjAz63uWEswM2li+I=; h=From:In-Reply-To:Date:Cc:To:Subject; b=OXShzImozh2sSZIu3n8hl0QvzxOh4bZ/DOrQbNu7SCiHjeOelPDTGfXftK5qx+6lX KMEKwsJH8erweCo9iLPDGY15mwchGZLctaOO715s8uNos9eHvPafj4MKFgltqmyPJw TuOnf9oHiIZlINwcNr8SQjVN8HwcfMIQ7BSvX2HI= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <010001790f25d43d-07a7c720-cb0c-494d-846b-91537afb94e9-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Tue, 27 Apr 2021 08:54:00 +0200 Cc: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <5722-6087b500-43-4f051c00@163630813> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 06:54:10 -0000 Hi Kent, > >> 3) should =E2=80=9Cee-certs=E2=80=9D/=E2=80=9Cca-certs=E2=80=9D b= e moved under the =E2=80=9Cuser=E2=80=9D node too? > >> 4) is there a need to provide a similar =E2=80=9Ckeyboard-interac= tive=E2=80=9D 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 i= t is the way I would expect it to be, all this new configuration is ser= ver-side only. > > > In ietf.-ssh-client: should "leaf-list submethods=E2=80=9D or "leaf-l= ist oids=E2=80=9D be ordered-by user? Right, yes, I believe so. > RELATED: In iets-ssh-server: should any of =E2=80=9Clist submethod, = =E2=80=9Clist prompt=E2=80=9D, or "list gssapi-with-mic=E2=80=9D be ord= ered-by user? Reading through the RFCs again, I think all of these lists should actua= lly be user-ordered, I missed that before. Moreover, if "list submethod= " is user-ordered, the default submethod should simply be the first one= and you can remove the "leaf default-submethod". > > But, our NETCONF library does provide some additional configuration= of the client SSH authentication so I will mention it and leave for yo= u whether you want to add it into the modules or not. We support custom= izing 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 indiv= idual methods, so that the unsupported ones can be disabled. But I thin= k 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 wit= h the "password" authentication when you have a public key configured, = for instance. > > The ssh=5Fconfig manage has: > > PreferredAuthentications > Specifies the order in which the client should try authe= ntication 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 > > We could support this either by: > > 1) wrap everything inside an =E2=80=9Cordered-by user=E2=80=9D list > > 2) define a =E2=80=9CPreferredAuthentications=E2=80=9D like variable,= to provide an external ordering > > Thoughts? This is probably just a YANG modeling issue. I was already thinking abo= ut 1) and it seems to me it would make for a nice configuration data, b= ut the YANG itself would be cluttered. Nevertheless, there may be a cle= an solution I am missing so it is up to you. We have simply assigned a = priority to each authentication method, but I am not saying that is ide= al. > >> On #3, this is likely mostly for me to resolve, but it seems to me= that *all* client-auth details should be under the =E2=80=9Cuser=E2=80= =9D node. Yes, a bag-of-certs (or a single CA cert) could be used to a= uth a multiplicity of users, but having that reference configured per u= ser (perhaps redundantly) is 1) more consistent and 2) better supports = the server being able to produce a list of =E2=80=9Cproductive method n= ames=E2=80=9D to return to the client. Thoughts? > >> > >> Separately, for background, I mentioned before that X.509-cert aut= h is a variation of the =E2=80=9Cpublickey=E2=80=9D authentication meth= od. RFC 4253, Section 6.6 clearly indicates this, as it consistently s= ays "certificate or public key=E2=80=9D, and RFC 6187, Section-2.1 like= wise supports this. So, we could push the whole =E2=80=9Chow to suppor= t X.509 formatted keys=E2=80=9D into/under the =E2=80=9Cpublickey=E2=80= =9D umbrella. That said, it is way more natural for administrators to= configure certs in their normal form then in the ssh-publickey form, h= ence why the ssh-client and ssh-server models have them broken out as t= hey are. > > > > But you do need to configure the public key for the user if you wan= t to authenticate it by a certificate, right? Assuming so, I think it i= s fine the way it is but I do agree with your points and see no problem= s with the change you proposed, either way seems fine. > > > If in your first question you mean an =E2=80=9CX.509-based publickey=E2= =80=9D, then yes, but... > > - if auth happens via an "ee-cert=E2=80=9D, the ee-cert for each user= needs to be configured, but it=E2=80=99s open as to if each user point= s to a specific ee-cert or if all users point to a bag of ee-certs. > > - if auth happens via =E2=80=9Cca-cert=E2=80=9D, the same statements = apply, but there is even less affinity, as typically a CA issues many E= Es. Yes, I understand, but I have too little experience with certificates a= nd practical use-cases so I am not able to decide whether the certifica= te configuration can be only per-server or needs to be per-user. > >>>>>> BTW, this introduces an issue as to if =E2=80=9Cclient-identit= y-mappings=E2=80=9D 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 authentica= tion 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 certific= ates instead of SSH keys, which seems to me is relevant for the "hostba= sed" and "publickey" authentication methods and would, in-effect, repla= ce 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 =E2=80=9Cpublickey=E2=80=9D= auth, so a =E2=80=9Cusername=E2=80=9D is still being passed in the SSH= =5FMSG=5FUSERAUTH=5FREQUEST message... > >>> > >>> Right, it takes me some time to absorb all the implications. So w= hat exactly is the purpose of "client-identity-mappings" for SSH? A cli= ent 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 sess= ion username based on the presented certificate and the cert-to-name ma= pping configuration. Am I missing something? > >>> > >>> Actually, maybe I can think of a scenario. Supposing there are so= me NETCONF clients deployed that use SSH for authentication but want to= identify users based on their certificates. Then there could be a sing= le username always used for SSH authentication but the NETCONF client w= ould map the specific certificate to a NETCONF username. That would all= ow the server, for example, to still implement NACM but effectively ide= ntify 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 userna= me 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 f= or NETCONF. I suppose a combination of this is also possible when the e= xpected 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. x5= 09c2n:cert-to-name) may be needed while ignoring the fact that the =E2=80= =9Cuser name=E2=80=9D is already being passed in the base SSH=5FMSG=5FU= SERAUTH=5FREQUEST message. > >> > >> Popping this discussion back up to YANG models, ietf-netconf-serve= r 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=E2=80=9D needed at all? > >> 2) if =E2=80=9Cyes=E2=80=9D, then do they override the base =E2=80= =9Cuser name=E2=80=9D value? > >> > >> For #1, I think you=E2=80=99re saying that flexibility is good and= , for #2, RFC 6187 seems to be saying that it=E2=80=99s a matter of loc= al 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 t= o be used in practice or simply not relevant for some reason and you (o= r anyone else) are not able to come up with any other, I think these ma= ppings are not needed. Just a note, we do not and not plan to support t= he scenario. > > Ack, and we shouldn't support a low-probability use-case. > > > > As for #2, I think I have suggested a way to allow configuring it e= ither way so that the 'local policy' can be directly configured. And th= at would probably be the best solution. > > I think what you are saying is: > > 1) if a cert-to-name mapping is NOT found, then fallback to the SSH-l= evel username > > 2) if a cert-to-name mapping IS found, then it SHOULD override the SS= H-level username. If you decide to keep this mappings, I was suggesting a completely gene= ric solution when you could configure a specific username for the cert-= to-name mappings. 1) If the user name is configured and a) matches the SSH user name, you try to use the mapping and override= the SSH user name. b) does not match the SSH user name, you ignore this mapping. 2) If the user name is not configured, you always try to use the mappin= g. But there is still the question of what to do if you find no matching m= apping. I suppose it could be a separate configuration leaf deciding wh= ether you want to fall back on the SSH user name or fail the authentica= tion altogether. Regards, Michal From nobody Mon Apr 26 23:58:52 2021 Return-Path: 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 4ADC93A10AC for ; Mon, 26 Apr 2021 23:58:50 -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 e2mzD1p07BtY for ; Mon, 26 Apr 2021 23:58:44 -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 82BD13A130E for ; Mon, 26 Apr 2021 23:58:44 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 2438F60084; Tue, 27 Apr 2021 08:58:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619506722; bh=RtbrHvobH3GyKZDObY8r5k4pQYTxakWo4M0A54ClhsM=; h=From:In-Reply-To:Date:Cc:To:Subject; b=VzLzHIhG3eoTfa2TDaEQLOwMMdqW43YAzMAzoS26tVy8Gor331QFH9lzPzn/5pSd1 t8+er7PbIR6F84hazrHz+L4YVCEKVjxmWeY668LyUiPHUv3TtKRhEh1cCvkr2sY2wc OfGahlSBhmtI23QZfMMBDvVMcHA7+pRgdOuJm0k8= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Tue, 27 Apr 2021 08:58:42 +0200 Cc: "Kent Watsen" , =?utf-8?q?netconf=40ietf.org?= To: "Juergen Schoenwaelder" MIME-Version: 1.0 Message-ID: <78fd-6087b600-7b-59cd2c00@214199368> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 06:58:50 -0000 Thanks for the input. So based on this my idea was simply to allow to c= onfigure this common use-case directly. But yes, it would result in con= figuring the password twice although once for the "password" authentica= tion, 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 wrote: > On Mon, Apr 26, 2021 at 05:06:48PM +0000, Kent Watsen wrote: > > > > * The sshd=5Fconfig manage says: > > > > AuthenticationMethods > > Specifies the authentication methods that must be succ= essfully 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 accept= ing any single authentication method. If the default is > > overridden, then successful authentication requires co= mpletion of every method in at least one of these lists. > > > > For example, "publickey,password publickey,keyboard-in= teractive" would require the user to complete public key > > authentication, followed by either password or keyboar= d interactive authentication. Only methods that are next in > > one or more lists are offered at each stage, so for th= is example it would not be possible to attempt password or > > keyboard-interactive authentication before public key.= > > > > > > As yet, with the current model, I don=E2=80=99t see a direct correl= ation to =E2=80=9CAuthenticationMethods=E2=80=9D, unless you think =E2=80= =9Ckeyboard-interactive=E2=80=9D is it, but that doesn=E2=80=99t 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 supp= ort > new authentication mechanisms, and if a separate authentication la= yer > is used, such as [PAM], then the server may not need any code chan= ges > either. > > >From a YANG perspective, keyboard-interactive is of course challengi= ng > 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 | German= y > Fax: +49 421 200 3103 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Apr 27 00:32:50 2021 Return-Path: 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 42AA83A17F5 for ; Tue, 27 Apr 2021 00:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 FTMdRBqTMX-p for ; Tue, 27 Apr 2021 00:32:44 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150074.outbound.protection.outlook.com [40.107.15.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7A33A17FB for ; Tue, 27 Apr 2021 00:32:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kaq8k1ER+NuYEqNwDjEUmDh+qed9NqDbgQFdsWSQT/7pi4uQLzbe2fzfjugo578zlkXnBd/m42cGVLrH6m6MRVY6VfBJjrKna42bd6nZXiw3LhnmStRl02JV1Uti9wDrSWfbCW/2DRP95Cm+AGwtAH69RCP39KhnAnH4LbG06tnEddqGp2nilCDN52eVIOAPzTTHm4/xKDEGj3P0H8w8ePtC9n2s1l5R/iN86Ydp8j0pDo+Zn1W0I/0nTUXXK5RzRJWM5a9xKoGiIkN6Wk1pjkQHOxVgt7Cb4UiWURVpDQShawAEr5Gd6lN1KVWaCl+sFeJaK8f6wlWgE9VNbRLFqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VUaQogQBuNogVE4xdeLcPvnSBqPMH7dtKaqojAlUvJw=; b=Uvzb1WlDm/Xx5eNlMerhxSAS5yXJG738uNSb315Y+LXYSSSL4hanZmgylBqKwzIbJn6aIX8TYMI1qU4eC1nqC7Z+THGmBOITvhD/qkMCYIXHrP1HYfZeDaBUfzz66+O+BLMaP4eE3iH2ve/5SJxmFVqU/xBrlQxGuNwtbhG6/oF8TzDNVIYvvI5mWdO8Fyw+O5hJK9pkXQA+bjQdfQrgMjaJxicv5u9usPHVR8P0fWGW/eiQIjjMnRvho8YmKml3LMornxBAg3FcfWOze0eRk2bbahz2icY216AjekvA8+2fxQLAoAZd9vtW/NosUkfkrVyb0LOrpT/9dvReB/ZCgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VUaQogQBuNogVE4xdeLcPvnSBqPMH7dtKaqojAlUvJw=; b=DGRRlXTvqdZgV30tfhYVwxKv+VjQT4iJEFp8iCtP8SgkyHlXoTYP72Av5G5f9nwBkOYN6aZTmNgqBNetb7zaD4wbIJlsLQmkld5qILYp6n531UuK0YPg2uVAvWuFQy3ZCcyXLgkMpPs+kdgowQfwBAos6rN79KqtbvoCN/2O7s4= Authentication-Results: cesnet.cz; dkim=none (message not signed) header.d=none;cesnet.cz; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1460.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3e4::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Tue, 27 Apr 2021 07:32:37 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4065.027; Tue, 27 Apr 2021 07:32:37 +0000 Date: Tue, 27 Apr 2021 09:32:36 +0200 From: Juergen Schoenwaelder To: Michal =?utf-8?B?VmHFoWtv?= Cc: Kent Watsen , "netconf@ietf.org" Message-ID: <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michal =?utf-8?B?VmHFoWtv?= , Kent Watsen , "netconf@ietf.org" References: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> <78fd-6087b600-7b-59cd2c00@214199368> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78fd-6087b600-7b-59cd2c00@214199368> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR04CA0030.eurprd04.prod.outlook.com (2603:10a6:208:122::43) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR04CA0030.eurprd04.prod.outlook.com (2603:10a6:208:122::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21 via Frontend Transport; Tue, 27 Apr 2021 07:32:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 19016a44-af2c-4f33-e46c-08d9094ea155 X-MS-TrafficTypeDiagnostic: AM9P190MB1460: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +wjA/5bPkNAqgB7/PV548qLBA6r9ObS90MOhVtAcC2P+gzHjPFBQW5v5AdtBSjElZSGnCAwBCrogLc/9M4X8yNkshnMhM+KKD/QMYe92dEsY5dqF+rnPDapLYW0ClH8dUfLr8xVKbAonfU0oFfxFkBxHBGvKUd9me91vre1ReXlc/y0P8x8AZ7f1/837oxuAQJOP1o5q12MjwZJ1VDS6wrzEu0gttqi9OhKk7nUe3y71nginq7r8T9zFTE6vXc2SIayNXex8H8p2D2ndEWJTkloTvU6mr4atDAok+9KCOpJHqHZQniLwKT0de1sslIWcHROufRYE9N/rCIuaHl87aMkIFHnUqKVemYgRWdJSuaT0JOf98h67JZj/lK7QpweM2kbOOaDULdjcv6x22JhfwzJJDqkUeW8FssNg9ju4KB7sBngq5zm6mq3ZnfyQGDOWfg4PdOCiEG3ctrvWVjV8ZDE/x2wO+q3kynFK48ODya11XFE8QumiDEJNU1O76DluU54pe+3f3JMM/Kqh28Zm2AFw+82HNkYMHS/4W5NsrDgRh8aXNjfsCZ3rEIwEInvabBoneLBf56Bnh+/UwxP1P7H21PfiJhu7TtkFBv+b5MRug9r2FnzUAluf7Th2eh+AOZwlSGrahmQ2v7wvmHu1mEoQb2Cpaz5lW74ptTTZqzky1CRSNKvluFmzf0tleANB6y1kNeCJAW35IokUMUcz8U6gex+AGk7r2wQWNbUF8cI= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(376002)(366004)(39850400004)(346002)(396003)(8676002)(786003)(6486002)(4326008)(2906002)(8936002)(966005)(66574015)(6916009)(3450700001)(6496006)(5660300002)(956004)(186003)(16526019)(316002)(26005)(38350700002)(38100700002)(66946007)(478600001)(52116002)(54906003)(66476007)(53546011)(86362001)(1076003)(66556008)(83380400001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?K0xzazh2b3pNZWF5RE9mdE5sVmltdVd1dGxsQnhRSEc0dWpCTmF2eXRjNVRo?= =?utf-8?B?dkxkRkVRWlg0SmFaQXA2cjhQU3NqSEJEN1N6YU0xeHNsY3VyNncxVm1UUjZs?= =?utf-8?B?MGRIdHRqTmYrSE1LWm9iRjlXR3RCYW1uWjVuNmVWZXdCSW9xb2dCaHY4M0lk?= =?utf-8?B?UUZiM3JZaHR2bUFzL1dsbGtSbGllbE9ERytNZTJYYjFOb3JuL3ZnUlo1L1lk?= =?utf-8?B?cldOMTRFczV3NnR0eWtaM0d4ZkRIb3lXT3E3aWhyaXdwaGxnakJIMS9nQjZW?= =?utf-8?B?a3ZmeUN5bHJUUjJ3Qmk0RFhWMkl1RkNUVDR6UzQwSE1Nc1hQby9OQXd3eitN?= =?utf-8?B?LzZHZTBIaGkvQi93OGI3VEZDckNuNk5KUjhyMmRxOEkzMytXcGF6Z2xJTjNh?= =?utf-8?B?TDVnd1JOUXNQZ3k3VFROSktIQ0g1bHVCVTd6MDhwdnltVDA3ckY5ZjF2d3V6?= =?utf-8?B?WnE1SDZncmlWSnJaNmxpUmdkMExsMkQzelRqTXRsK1kzMWVxWW84eEJYSEVB?= =?utf-8?B?MlVDTk5BaEMrUnptSFBDWkRHNit5THVMSExBeU41eUFZTCtDVjNLSy9sbGJL?= =?utf-8?B?VkQ5ZjRqbkd1dWNsNmZuSXdDK0tYL0UyZFZ6czI5ak1CRWlMSW1UaXlFRTVO?= =?utf-8?B?RUZxVEdWemx0N3JWQzR2Y3BXcUgrVEcwZVNlL1kvejJyZklVaG4vRVZwemJ5?= =?utf-8?B?elRoK3JZVUlQaGpiZ3E3cVNlYzJhNFZGS1ZPQ29UMjM0SlB0R1l0bWU0SkhF?= =?utf-8?B?Rjc1cG51RDhOakQyRkpqczFJMkdRV1EwdEhjMGFvdmE4bEpqN0tkSmNYK2cr?= =?utf-8?B?VFhQZzJIUEdVZk1kNjZSbDNxVERUNUFqQTRSSG8yOSs3SlF4eWh6QWo3N3dh?= =?utf-8?B?OU5sTVVSU3ZOWWpkSzZQblFwRHAraFZlS0xSci9zNXhsNitEam5zQWczR0hx?= =?utf-8?B?SHZqZUZIU1QzOHNjSTZQQy8vTWVSd1Uycis5L2g2RVNCNHEza3lyL2VCd1gx?= =?utf-8?B?T1FXRGtaY2o4QTc5WTNtRzJENW5iR1JsUTlKeEdvVDFZamh0NXZxVjZ2V0Fr?= =?utf-8?B?U1h6Ky9BbkVjOUI4bktsUkhPTkppRUQvR3VCQjJ6eW9KYkkxQXBiYTY4SlJN?= =?utf-8?B?aS8rcm9oVi9ZbzEwK3FJUFlieTU0bzlhSldVZi9pYUJhck9oYjYwdHE4dms4?= =?utf-8?B?TWxUUEgyaWRQR3F0ODkxZGNUMkpXRUMzS1NxbHB6UTR0ZmxBN2ZBcTU1bHFI?= =?utf-8?B?Z0hPYjMrZjdzUXI5RTFybUpKSGNHWm90NXFJdjlGenQ5MHQzcld6dmxOUlZO?= =?utf-8?B?UDZWT2d0VHlPcnBrZFJyalV0TWY3ZGJ1Wk5lbEVqOUg3dGZtd0hvY29WUHA3?= =?utf-8?B?cmJQcTE3K0F0bzlxSnpvUiswclh0dWpkclBlTWxzVnd3U01XWm4wWDFtVWxY?= =?utf-8?B?Vk5YNW93dndoc2Z5RWN0SEFFcTJDRHJueGJVc1FXZW15bXpDeUw5a0l3NEJ3?= =?utf-8?B?L2VjeEt6aHQzb01FZHdyR2JOOXpGczhrdkVHN1BoR2kvb1FMODNXYVNuc2JU?= =?utf-8?B?YXhTOEtocW9Ccm9RQmJCakMza3dNMXpSc2RpQmtkZUd1WWxpWTFELzJDWHlU?= =?utf-8?B?enJqUyt1OThlMHQ1a0FNcm12dlVwUXZHM3gvQzBCS2ZzRkVUZVMxQ3VOQlg4?= =?utf-8?B?OThBcmlxWEE3SGlQUDFxN1lUUjdzSW03QW40bW9vcXljVFlHOUU2dHRXcjB0?= =?utf-8?Q?CSHL2NdO/2C2a20xHqXl4a7NXBeNSpcJI5FH1bB?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 19016a44-af2c-4f33-e46c-08d9094ea155 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2021 07:32:36.9799 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YzbzJRAh7AJEyw+PDWt6pI3q+gb3mwqTgqUodNY02fGH+rtcHZZFUoToh/oa6QKEC/ayGzQUlzbvfhkmKwp7PNvb4jMawcjNuiJ5PScvQHc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1460 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 07:32:49 -0000 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 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 > > > > _______________________________________________ > > 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 From nobody Tue Apr 27 07:24:48 2021 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 ; 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 ; 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 ; 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 In-Reply-To: <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de> Date: Tue, 27 Apr 2021 14:24:41 +0000 Cc: =?utf-8?Q?Michal_Va=C5=A1ko?= , "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 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 14:24:47 -0000 Hi Juergen, Are you saying that a client SHOULD use the =E2=80=9Cpassword=E2=80=9D = method for password-based authentication? That is, from a modeling = perspective, the =E2=80=9Ckeyboard-interactive=E2=80=9D method=E2=80=99s = =E2=80=9Cresponse=E2=80=9D node can remain a cleartext value, even = though it MAY contain a password? Note that, on most servers, the = =E2=80=9Cpassword=E2=80=9D 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 =E2=80=9Cpassword=E2=80=9D method), but rather in an external = DB (/etc/passwd, RADIUS, LDAP, etc.). Hence I question introducing a = =E2=80=9Cchoice=E2=80=9D node to the =E2=80=9Cresponse=E2=80=9D for = iana:crypt-hash or encrypted values... K. > On Apr 27, 2021, at 3:32 AM, Juergen Schoenwaelder = wrote: >=20 > 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. >=20 > /js >=20 > On Tue, Apr 27, 2021 at 08:58:42AM +0200, Michal Va=C5=A1ko 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. >>=20 >> Regards, >> Michal >>=20 >> On Monday, April 26, 2021 19:21 CEST, Juergen Schoenwaelder = wrote:=20 >>=20 >>> On Mon, Apr 26, 2021 at 05:06:48PM +0000, Kent Watsen wrote: >>>>=20 >>>> * The sshd_config manage says: >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> As yet, with the current model, I don=E2=80=99t see a direct = correlation to =E2=80=9CAuthenticationMethods=E2=80=9D, unless you think = =E2=80=9Ckeyboard-interactive=E2=80=9D is it, but that doesn=E2=80=99t = follow from the manpage snippet above. >>>>=20 >>>=20 >>> 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. >>>=20 >>> [...] 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. >>>=20 >>>> =46rom a YANG perspective, keyboard-interactive is of course = challenging >>> to model since you end up modeling something as flexible as PAM... >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Apr 27 08:55:59 2021 Return-Path: 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 62E653A1258 for ; Tue, 27 Apr 2021 08:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 dJw0gbTBydxa for ; Tue, 27 Apr 2021 08:55:53 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20074.outbound.protection.outlook.com [40.107.2.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573E63A1252 for ; Tue, 27 Apr 2021 08:55:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J0OoTzsmve0XMLSdGbvmOjuO2h84ITxSkp0TXNzktilHJoXn7FC6Zkjgb3dK7CJCIMmhypEj2umfAppIfanCCmW9vSDGsOVxkFwVWtRZKgoFtlWcDHN5fcgZ6fp/5TB1p+HSCiLhOQyOiNQhrti83htwsxctW5++y4X9DRZ2etA2n1QoOl0uK03SbWp8nQsPLZOzGE1C1VDyV/cluRBj7j7F1J/HWIUhP8sdcL69qtsHIRxYbH9UY+uaQ6Bo2+I2S8LXMPd7UK+nbvx+3LYU3t1o0ujnqtYjaaC/iYpXLP7F/enEOJLv5mgbESBDBVJss7qkDWNZFw0I2BZR67rtMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N5Z5mU9yyIOlt0aBmF62oNp2rlXzYzjtwPz/rrp0qNU=; b=NhLUoXowFf+w7uDw5BhmqIeRYltdgI4rbqKSjKU1SMA1S54n4BsISiObMc3HVxIXaEIV6DPzkodJ0t9NiqxjAYJ5DMP946iGfjqgsyasbjBCKSZbJ/5fsl+zD2PKOKl/pKHqVCzgu34EsQ92g0yY0zADEpsWJZkK7xFCqRMrAlOaGxXX5a0AiIO/VZ+txEn+hzKm+1h2BowuAuxcffiZ3MvgSK7SCiRWIiCn+jIbJFAQkyT5pmBDeO498OYmMR2loWZDF7Z4oljunBOs4SBE9ueif2VP/uOzZ60mT+nY+lh1NTnoduzCKlW/zhKFpbnmfe3Kz0Q/ZhZ991ZIbQgMUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N5Z5mU9yyIOlt0aBmF62oNp2rlXzYzjtwPz/rrp0qNU=; b=Wu7InfA6lT2geLPib41c6pm9jtphOEM4HUcVq/BjFm7ZfPt9mJde/OyurpKuOPRxJf2AmIRb7K47U8muW1xaZiGGvqF26fSE1P+DXidwZn1coJX8few6+6vQ9hoX+/+pBnAtL4/LKNEZvOrR64wrigY12c0vu2xuZJoDO1j3bn4= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from VI1P190MB0656.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12b::14) by VE1P190MB0976.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:1af::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.22; Tue, 27 Apr 2021 15:55:47 +0000 Received: from VI1P190MB0656.EURP190.PROD.OUTLOOK.COM ([fe80::c9fa:272c:2405:db89]) by VI1P190MB0656.EURP190.PROD.OUTLOOK.COM ([fe80::c9fa:272c:2405:db89%8]) with mapi id 15.20.4065.027; Tue, 27 Apr 2021 15:55:47 +0000 Date: Tue, 27 Apr 2021 17:55:44 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: Michal =?utf-8?B?VmHFoWtv?= , "netconf@ietf.org" Message-ID: <20210427155544.pd7bmt2hdztx2zui@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Michal =?utf-8?B?VmHFoWtv?= , "netconf@ietf.org" References: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> <78fd-6087b600-7b-59cd2c00@214199368> <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de> <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM0PR02CA0151.eurprd02.prod.outlook.com (2603:10a6:20b:28d::18) To VI1P190MB0656.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12b::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR02CA0151.eurprd02.prod.outlook.com (2603:10a6:20b:28d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.22 via Frontend Transport; Tue, 27 Apr 2021 15:55:46 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 19718986-ea83-49af-f1f5-08d90994ebe8 X-MS-TrafficTypeDiagnostic: VE1P190MB0976: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Sc+/v6NrNnyMN1VH0tKy3j4fXyr0KFDkvdip8psy9x1x8nqEqSUW6JNMVq7jo7bVS5zFnEivIAag3L5WTPf6ghsU54NTBarL1d+nGFFHbD2rIQmFORi0dOdSODLJVPjdcSvYMsM90QQ48DsBaJQbCdhQVLB5Wva1CRmbtEoOH8fFqQ/z+0x08xt2I1VDFbWgk7FcszEOTLZSTejrlit5GQnnIy5V5SRaKGQIwr36b4VVwAFxb5TaYsAv0RZad6xovcmADPOMOEhurU+avXwG4HaC5xtmoCgC8ZdddtkLqyBTxj/YabvmCg0J1e084Oj6+2BdEuRZF2tQ4I7p4/SzNqMvdRrmdbyucRCDy/rZIoo93GCDi/Ih4OFowxW7sOvfXQ2yeNAYbkbdDSwQyPvB/R5bThTZ2dmJX37Z6oJ/+XASQQSffKJRLRed+KNVOrfuWdhCyiPv7PT72wiSqkyjOBkfW0VWOn+hwiCa61tVxAzfeEpkydHDG9mwoXQbcLM6ZYot8WnMBJtrpGnchmCY9caRwCxM0LRNw65Pg0F96cnPZjAs951bbbRigTWCmoXlqLbm9096x2ChT6TMRAgbtBHxtlohoACLWWxGSR1qvV+Ydj32+/i2dRkbhbCXmjh8IAYQD6UiQsitVXxCIhCwsNbyJ8BGBYamWV1Kc8eNIuIK4QSqhjxWlp4/1YQQoSjePzcamG+A81+0l69BokJ8hEEoa8LVXTGq4Qv84eJXeMhhiIfYRoj6b9VIEDBHKprGknUoX8P0XhYaVDLPo+XiQg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P190MB0656.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(346002)(376002)(136003)(396003)(39850400004)(53546011)(38100700002)(38350700002)(66574015)(8676002)(966005)(316002)(956004)(786003)(83380400001)(3450700001)(52116002)(2906002)(54906003)(86362001)(66946007)(66476007)(26005)(6496006)(16526019)(5660300002)(1076003)(4326008)(8936002)(186003)(66556008)(478600001)(6486002)(263294002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: M54cLfkU6zIukx+jD6qAJTsvDh2i2N0z9s84PFtoWBj6R2QWhLt/kvjvDVZvxFBEjVuoAcE5hEdvg7Z+iZkJ3YhE9BQP7LzEiFNugETN2GUpgHTBIJsJMCCVYCqnbSEssqm8CYMLu5NuKbTKQ3P37GUuAJAyFnaNoQTdUjOdYVaWO3CUzj5YYwXSG5MpYA2iTN+mkKD7DU3Tm8e6PpUs7c41yGKwpa3XP0D+UQ+aIeDi/sDoLgoA9poXthd1fv4EYUdLPmGt/kAkn4Rk5OtYKrXB4oCeK7ZP3MbjHFJr7AuN2LWYPBDvlD+HBYsxJfczQ4OtOO+5+6bzQXEGB4j322Rom6s8ylYIFPb2OkyCBP+aflR8gikTBGUCn48eE/Jvb3pRsmWboB9jrnXWEaDvzBs1Rwmx91QISz5AWh3rAtF8Ah8QWKPOFjM+nOR9hushmC0iZodJVfCcl3+5BL5x6MFkpX5cNQBdr/13T8pBMZq3RxWQS4J4W7CMwUEh4okZprtdvzvtD5uV2i0gW7S6ejqEhybdEmWNZCMd1K0yB95S8yRUI8chUwbxW5/DEnq5VfNsGg362upKTstFL9q38MC/0CuCI7IqzujtfJRpl426SN6/FW3jZVCCVeyLop8d8eDixG7rVpJiVcbxD6SVcezagxAeKDPFl3NwFuOa+fyKI1YYaAlfrS8q4iB+MDGv4fK4iZljVgzDTacWhU+j+J/NRtyYA1KLVcPClcfnJXQ4I0X+7DmZSNCwo8NjlRT6 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 19718986-ea83-49af-f1f5-08d90994ebe8 X-MS-Exchange-CrossTenant-AuthSource: VI1P190MB0656.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2021 15:55:46.8920 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: tdxGHoXMsQlR4ADOley+PMNRAe4wEvWNAfvpM4RZssf3UD+JEUpTRAazfzzJpoV9C5o7ggR/y9S9d9lvhsldJ1aVOEkUzUtUlI+RkJqlS+A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1P190MB0976 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 15:55:58 -0000 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 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 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 > >>> > >>> _______________________________________________ > >>> 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 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 27 12:08:09 2021 Return-Path: <0100017914bb076f-9fb97a64-b35a-474d-9222-9be5ec784aaf-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 6FB693A1C83 for ; Tue, 27 Apr 2021 12:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Z6FTqbXp53d8 for ; Tue, 27 Apr 2021 12:07:57 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0803A1C5A for ; Tue, 27 Apr 2021 12:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619550472; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=FtBwnFhNaW0Rb4Ahz3iW3keEbqW+7e/zifkkgtBZJ0M=; b=kE2JPvIk4doE0k15zHLd1TBnzYP5RuyJeRUSm8JQVS75Jwy2B9PwX9CNbLk1/uEM lJO4yjBynRS55v/slwXFUbUuPLYxnVqawhTFtCJU1MtBXl+YsuOp6olhrlsq62YaS4b Vg4MSppdZq9pxzZB965f3cGdKUspKkASvDcQs25o= 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 In-Reply-To: <20210427155544.pd7bmt2hdztx2zui@anna.jacobs.jacobs-university.de> Date: Tue, 27 Apr 2021 19:07:52 +0000 Cc: =?utf-8?Q?Michal_Va=C5=A1ko?= , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017914bb076f-9fb97a64-b35a-474d-9222-9be5ec784aaf-000000@email.amazonses.com> References: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> <78fd-6087b600-7b-59cd2c00@214199368> <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de> <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@email.amazonses.com> <20210427155544.pd7bmt2hdztx2zui@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder 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.48.94 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 19:08:07 -0000 Hi Juergen, I=E2=80=99m familiar with how PAM et. al. works. The question in front = of us is what the =E2=80=9Cserver=E2=80=9D models should look like, = specially the SSH and HTTP server models, as they are the only two that = have a =E2=80=9Cusers=E2=80=9D subtree. The TLS model (just like the SSH and HTTP models) has a = =E2=80=9Cclient-authentication=E2=80=9D subtree, but it=E2=80=99s wholly = leafrefs into the truststore, and hence no =E2=80=9Cusers=E2=80=9D need = to be locally defined. All three models have a "client-auth-config-supported=E2=80=9D feature = (possibly better named 'client-auth-local-config=E2=80=9D) that enables = the =E2=80=9Cclient-authentication=E2=80=9D subtree. This is in = recognition that the models can go only so far, and it=E2=80=99s = expected that application-specific augments may be needed. In my view, the TLS "client-authentication=E2=80=9D 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 = =E2=80=9Ckeyboard-interactive=E2=80=9D isn=E2=80=99t simple, my query is = more in terms of the total number of users=E2=80=A6] K. Disclaimer: I have no hands-on experience with either the SSH or HTTP = "client-authentication=E2=80=9D nodes. My RESTCONF server implements = the "restconf-server-app-grouping=E2=80=9D and supports both TLS- and = HTTP- level client auth, but it uses the "client-authentication=E2=80=9D = node only from the TLS model, as it was more intuitive to maintain a = distinct =E2=80=9Cuser=E2=80=9D model than to define users in the = =E2=80=9Chttp-server-parameters=E2=80=9D 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 = wrote: >=20 > On Tue, Apr 27, 2021 at 02:24:41PM +0000, Kent Watsen wrote: >> Hi Juergen, >>=20 >> Are you saying that a client SHOULD use the =E2=80=9Cpassword=E2=80=9D = method for password-based authentication? That is, from a modeling = perspective, the =E2=80=9Ckeyboard-interactive=E2=80=9D method=E2=80=99s = =E2=80=9Cresponse=E2=80=9D node can remain a cleartext value, even = though it MAY contain a password? Note that, on most servers, the = =E2=80=9Cpassword=E2=80=9D method is a lookup into the local users = database (e.g., /etc/passwd). >>=20 >=20 > 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. >=20 >> 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 =E2=80=9Cpassword=E2=80=9D method), but rather in an external = DB (/etc/passwd, RADIUS, LDAP, etc.). Hence I question introducing a = =E2=80=9Cchoice=E2=80=9D node to the =E2=80=9Cresponse=E2=80=9D for = iana:crypt-hash or encrypted values... >=20 > 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). >=20 > 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). >=20 > /js >=20 >>=20 >>> On Apr 27, 2021, at 3:32 AM, Juergen Schoenwaelder = wrote: >>>=20 >>> 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. >>>=20 >>> /js >>>=20 >>> On Tue, Apr 27, 2021 at 08:58:42AM +0200, Michal Va=C5=A1ko 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. >>>>=20 >>>> Regards, >>>> Michal >>>>=20 >>>> On Monday, April 26, 2021 19:21 CEST, Juergen Schoenwaelder = wrote:=20 >>>>=20 >>>>> On Mon, Apr 26, 2021 at 05:06:48PM +0000, Kent Watsen wrote: >>>>>>=20 >>>>>> * The sshd_config manage says: >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>>=20 >>>>>> As yet, with the current model, I don=E2=80=99t see a direct = correlation to =E2=80=9CAuthenticationMethods=E2=80=9D, unless you think = =E2=80=9Ckeyboard-interactive=E2=80=9D is it, but that doesn=E2=80=99t = follow from the manpage snippet above. >>>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> [...] 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. >>>>>=20 >>>>>> =46rom a YANG perspective, keyboard-interactive is of course = challenging >>>>> to model since you end up modeling something as flexible as PAM... >>>>>=20 >>>>> /js >>>>>=20 >>>>> --=20 >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 = >>>>>=20 >>>>> _______________________________________________ >>>>> netconf mailing list >>>>> netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Tue Apr 27 14:00:57 2021 Return-Path: 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 B28A03A2058 for ; Tue, 27 Apr 2021 14:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 OdpW3nzTIXet for ; Tue, 27 Apr 2021 14:00:52 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2080.outbound.protection.outlook.com [40.107.21.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB183A2057 for ; Tue, 27 Apr 2021 14:00:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cf97eu6O9lR2tgK/X79iR4+lg4eBdwNAlSw6ALM26MmbldcxKyfJpAEEqSORKst7HFPiOg+/8Vj25886JjKfBFo6/m2bhI5EqJuHD3vYpZWFToTsccfZhXaAFYE8hxzzRmMLkMezL5X8/ngFDiK2aWCYVDVlXs8pzPGnzxuAUegImeSpy75riEp2yVxPO0e3OVO5Pxb4R8iAC2Uaq3VAmQE75qn0sqUQTmo5jrhCGoGIW1pBBF1uFFLhAzsdUOIWsicb4XED3pSiKFdHxGQK9AijZ8F7gKZQSC08SpmrgvYnW8CwdOzR+iEGAvCCNlg7TyCYYENU4/MmjpflzqxCaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=heeZ7SI4kOul2c2m4Jtd8/2E+Cw4MptzhB8QfvwOVj4=; b=GYSOK9GjY26DMLK9FHL5ADYZiO0xDlurnQzlN8utnRTLNByFq+VP2pgrKTgi754cH4IADMgsrmHntFLJNdT1LxMJjb+BhHXUYl7PRQQS/6Sop0mDnkS+HahQMLODKhM9Hrs9tj09uo3EAIRAC6YPALgvFCl46P/v5rufJ2HW1U9Dvp0MJnbnf5OHXgE/4OKw46u40nTVYNHdPwrd7VjKW3CLN+QTMVnmfaW/JuVwvzhenYkGlPcV9Mo73FrzwWUxXSKJnaI7Rvgot5vf2p1MeeO7t6z2N2sPHgoqgB/nZucEahwaU6fsh5dLSX/eg6ir6dDFDziDUxqA4ATOxAkyIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=heeZ7SI4kOul2c2m4Jtd8/2E+Cw4MptzhB8QfvwOVj4=; b=R3qev2gNpFcC8ujHtt9qyVQoMHiP2J4JLPC8E1fsbtZ6DbTGwf5z/R0xLaGzI+iiB0uY9iQC8rYnweN+c6avMfmlIzsfBtnqbDHENrCVm3FZxZhJE8Q+VXLcL1lNNPKVgjZFxaqw1HWduuxmUH877CH0vX38kkNoqfAC0jAErjk= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1444.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3e9::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Tue, 27 Apr 2021 21:00:48 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4087.026; Tue, 27 Apr 2021 21:00:48 +0000 Date: Tue, 27 Apr 2021 23:00:46 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: Michal =?utf-8?B?VmHFoWtv?= , "netconf@ietf.org" Message-ID: <20210427210046.gtfcwwf5kefxfme5@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Michal =?utf-8?B?VmHFoWtv?= , "netconf@ietf.org" References: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> <78fd-6087b600-7b-59cd2c00@214199368> <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de> <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@email.amazonses.com> <20210427155544.pd7bmt2hdztx2zui@anna.jacobs.jacobs-university.de> <0100017914bb076f-9fb97a64-b35a-474d-9222-9be5ec784aaf-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0100017914bb076f-9fb97a64-b35a-474d-9222-9be5ec784aaf-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR3P189CA0064.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:b4::9) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P189CA0064.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:b4::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.22 via Frontend Transport; Tue, 27 Apr 2021 21:00:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 91f53f95-9aba-4682-e630-08d909bf8850 X-MS-TrafficTypeDiagnostic: AM9P190MB1444: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OBPSkZkkFOcebY9XULn/iq/I5mN4WYbrNThuwGjh06/RtnV3+01hv6nMybucAWsgAQUUGPwZBcKdokQVBZ7m8rV+umoLnovJvpn8g7mrlInHkvk2M5eZJNE5YKR/VWfAQHFEG9a7Xu+JAgJTPZuuIAoUZi8v3Z9d+Vy7WrSIVfpsuqMJ0q815898QEaeHazoz03qwn96U90BIF059gR9Ngcl4fGqWtanfOt2rCwdoGIbx5GEI73+wKzBWGnFzvGDx/83odRL3eY8Xtx4QB8G69Q8ldpMZFUf//TGTKGBkSYGFCowSWjq8Oe1wyOCkupubJ23IoQGMcJpFqaGH98Ju8x14TnRo3HmvD/vXX1I7ajW3bBBos5Kjrnpc1D8Uuk68uM/BHS4VdjcitrYtwx/RtPJ2DIppf9qV8fsj5IGwDNv3P1LIpJlCcCzNJVLrIgJ0g9U//bYigJBqvtEgAQgSahj9lYAYhdRbKz+Xoad/s5n+XxpIrn5BX1JrqV9XOen6I7UpumbsWEqcm254Nkp2At5MuuBfQ1N4jpVUdvnXXtxsHQisfQTZDcqtMQv4jhucAu9N6ch2T8SkM9jupvyRNSD2ED5cTMdjrurHXklacY32KFx1is5p8vVtnmYOO+k4jkZI9c+EI3K75W3e6SmXo2euGbcljZrKTzmPtqNbd/sb7wxtawA8fhE/KSXAZQUrNm5Snm+XdAaj6SHnC452ya56TwcCCILm7ItXzfJMvslixG7rYRCcGcHnoWr6c5IsyLJ+3Ze6kJZHojjElx7Ew== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(376002)(39850400004)(346002)(136003)(396003)(316002)(786003)(1076003)(8676002)(30864003)(4326008)(5660300002)(54906003)(6486002)(966005)(6496006)(8936002)(86362001)(956004)(478600001)(83380400001)(26005)(53546011)(16526019)(186003)(66556008)(3450700001)(66946007)(38350700002)(66476007)(38100700002)(66574015)(2906002)(52116002)(263294002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?OCtpaEplRzlrcDV5ZFNFWS9WL214cDVWbXhqZWdjd1ZWV01pZTJxU2tQWHdx?= =?utf-8?B?V1NiQ0ExU2pFTnNrU21NOWFBa3JJZU5WbUYyNFBsQmtMcjVwZ05UaURrSHVW?= =?utf-8?B?OTc3VWs0TmU5ckQ3dVg3MkxFUFA2dzlYb2VCaFk4cEpKMFFibW56ci9HVzY4?= =?utf-8?B?NEtxcTY2OFRBMUQvZDczYjJvNFVGTzBuMUw1NXJlUHNtK1hFbUMrM0lWL3o2?= =?utf-8?B?eUUrVVBjdUV6RnpYdGZMOG94dnBEZTlXS0lDYUdMY2hTMzBtZlNjbUw5N2Ja?= =?utf-8?B?SEtjT1ZxZVRZQ0RmU2QrbU44SlJoZEhzKytHSGxvQU1yY2V5UWhzOG1IZFdG?= =?utf-8?B?SisxOTMxM1BoV1Q1Z3pGNHJBMnpWUnRSOUlwYms1YjRFbStnaHJmUGFOVnZs?= =?utf-8?B?UGo0RnlJem5hK2pmTnVNOEFad1hOZ21vQUZXQUhFQjZpNnlEOXBXckUzb1Nt?= =?utf-8?B?SDhnOUtiTldPbE91U29KaTlsZ01jSCsrSEhlczdBeG1yS3J4SUxQcC9VbFJV?= =?utf-8?B?VGI2WUd3aWNDL252ZnJtbVQ1T2xoUm9YVm5CN2NEditDUHBlMnlPREw1MDQ1?= =?utf-8?B?azhTR0xNUzlpOFZ0WVBpS3RCZmFTdWMySXNyZklyV3dQcFJ1QXJUYUE5T29L?= =?utf-8?B?UG5Ra0FncWJ4ek1wMVROQWhlZmEzYjlzU2tGZHBNTEJhYTNybHNYV29WRFZ2?= =?utf-8?B?RGtrbzlRVndlUDBLMWtNZlRyTkMyN3pPZk9PenQ1RjU4SlcxVThoR0lRcDR5?= =?utf-8?B?WmZKcnErMllhb3RKYm5qZm1HaUdSTTI0Y2pqNTFEN3BLamEvb1dWY0xaZXpo?= =?utf-8?B?bWhZcHppQitiL3B3NWE0dTJTbzJublVYTTNTRjBYaHNLNS9GQzRHSC96UVkr?= =?utf-8?B?a0hqS1NMdmx4TWZlVHI3M0RDZi9UVDZOeFJOSlF5MmFpOUw2alZCTUNhbHVh?= =?utf-8?B?NzdrZXNHNytmM3ZndEo0ZU9MYUlqR1JiWEVueWhDL1oweWtHZ0I3Z3Jscmcy?= =?utf-8?B?RVRLV2FGSXlia0F5ajFBVzY5WWdUdjRHOUlKRUV3RkRPNGY1MW5zYTJqWW9D?= =?utf-8?B?TTBvUUVmRFgyRU1ZaWVWVDZyZzVic0pVRElva3NScVlBVzIzbHM3OEdwcDN3?= =?utf-8?B?bWdQbVBtUjFxR2NBbDNrbmtaWHMyU0tLTUZhTk1nMUNsbUszQVJWNUUyWFNm?= =?utf-8?B?OEkrZ2JEVXZIOVNDbmtWaVVGWWVsZUMxd2hSdVJ6NDY2M1l5bGU5aHc3M0tn?= =?utf-8?B?MGFpNVIxUnM2Z1RoZTM1SmVFci9CS0lMSk9UWGcxUnc1N2tvNUk5aE1JZ3A4?= =?utf-8?B?RFQveStZVEp2dzFKZmtUdmpxcVdyc3Vta2JybFZCU1B0NU5qdS82QTdObDJ1?= =?utf-8?B?cGNZMHhZQmlPNkkxbHErcDVvY3ZyeHZGQm5FeG1qVEVycnk0SzZWZXRjeUg2?= =?utf-8?B?eHR5L0tScG1DaTRzaGhoY09kYzJTNlFTbFVPbzR6L2ROZVNGRHhxdnF2SGx3?= =?utf-8?B?L1hWamlJVll0Nk9zVS9IUGRtcDUvM3BvbkE3ci9XT1BsdWFGMGRWZ2ZXeDBt?= =?utf-8?B?U0hRcTNkZEQwbUh1SS8xRjAwaVZJT2hQYVhRc1JIcHZodWNvdXZ5MFROS2Nt?= =?utf-8?B?M0M4WHMzcWg2dG9Sc3B3bSsrUjQzR1lpTDR0TklvVHM2SENvMzV4TGkxdjRq?= =?utf-8?B?b00yWmV4WEpKcnYzSmFURTZrZWwvamdVNWF6NXh4NGsvbnllZVREVU0yNlpC?= =?utf-8?Q?B1bW74HjScor1ThQukT4YTcusIjw7HAdjGW2nTX?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 91f53f95-9aba-4682-e630-08d909bf8850 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2021 21:00:48.1565 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: c5oZDCugwdptXHvbzOQILr+Jc0mUvWg6xwRDF/V3q0tCqcj7swnd/JUa3JX4y/devTXqGNMvc2J5cD52vgSt90Vx79k8WS9G4OzkHl83Cpo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1444 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 21:00:57 -0000 On the SSH server side, we have this: | +-- users {client-auth-config-supported}? | | +-- user* [name] | | +-- name? string | | +-- public-keys! {client-auth-publickey}? | | | +---u ts:local-or-truststore-public-keys-grouping | | +-- password? ianach:crypt-hash | | | {client-auth-password}? | | +-- hostbased! {client-auth-hostbased}? | | | +---u ts:local-or-truststore-public-keys-grouping | | +-- none? empty {client-auth-none}? | +-- ca-certs! | | {client-auth-config-supported,sshcmn:ssh-x509-certs}? | | +---u ts:local-or-truststore-certs-grouping | +-- ee-certs! | {client-auth-config-supported,sshcmn:ssh-x509-certs}? | +---u ts:local-or-truststore-certs-grouping On the TLS side, we have this: +-- client-authentication! {client-auth-config-supported}? | +-- ca-certs! {x509-certificate-auth}? | | +---u ts:local-or-truststore-certs-grouping | +-- ee-certs! {x509-certificate-auth}? | | +---u ts:local-or-truststore-certs-grouping | +-- raw-public-keys! {raw-public-key-auth}? | | +---u ts:local-or-truststore-public-keys-grouping | +-- psks? empty {psk-auth}? On the HTTP side, we have this: +-- client-authentication! {client-auth-config-supported}? +-- users +-- user* [user-id] +-- user-id? string +-- (auth-type)? +--:(basic) +-- basic {basic-auth}? +-- user-id? string +-- password? ianach:crypt-hash What exactly is the problem? a) Is the issue that there is no support for keyboard-interactive in the SSH model? b) Is the issue that there is no support for non-local user databases for SSH and HTTP authentication? Personally, I would be fine to go ahead with these limitations as long as we have the structure in place to add things later (e.g., once vendors have prototyped extensions paving the way to a standard solution). /js On Tue, Apr 27, 2021 at 07:07:52PM +0000, Kent Watsen wrote: > 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 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 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 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 > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 27 15:45:27 2021 Return-Path: <01000179158224da-a7663485-0b99-42b8-b85d-804c9d17ec5f-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 83ED23A23D3 for ; Tue, 27 Apr 2021 15:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 hL2xeaOM5Hy8 for ; Tue, 27 Apr 2021 15:45:23 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAFD3A23D2 for ; Tue, 27 Apr 2021 15:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619563521; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=KSnzGvrUdPTCWpSLklKc05fkUbN6sBxjaajRUy/jN2g=; b=VrQEPrQoueKTGB/8sLSVYUqolAgvv8r1UJYZ3IDGN9PJNvYNoIJb4a9WTxwOn9QP PqZ01Tj9sbMzwpPOMOI3d2KtYYxxOH7etm2JeX6hwt1lVudoKwJIn5UDQW3J5068mp3 +WTonlUZ1s0tOmZB57hepof4+m0LxAxhIxR5pKWc= From: Kent Watsen Message-ID: <01000179158224da-a7663485-0b99-42b8-b85d-804c9d17ec5f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_54FE5B1B-81E0-49D8-AE2F-E77BAF17B486" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 27 Apr 2021 22:45:21 +0000 In-Reply-To: <20210427210046.gtfcwwf5kefxfme5@anna.jacobs.jacobs-university.de> Cc: =?utf-8?Q?Michal_Va=C5=A1ko?= , "netconf@ietf.org" To: Juergen Schoenwaelder References: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> <78fd-6087b600-7b-59cd2c00@214199368> <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de> <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@email.amazonses.com> <20210427155544.pd7bmt2hdztx2zui@anna.jacobs.jacobs-university.de> <0100017914bb076f-9fb97a64-b35a-474d-9222-9be5ec784aaf-000000@email.amazonses.com> <20210427210046.gtfcwwf5kefxfme5@anna.jacobs.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.96 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 22:45:26 -0000 --Apple-Mail=_54FE5B1B-81E0-49D8-AE2F-E77BAF17B486 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Juergen, > On the SSH server side, we have this: >=20 > | +-- users {client-auth-config-supported}? > | | +-- user* [name] > | | +-- name? string > | | +-- public-keys! {client-auth-publickey}? > | | | +---u ts:local-or-truststore-public-keys-grouping > | | +-- password? ianach:crypt-hash > | | | {client-auth-password}? > | | +-- hostbased! {client-auth-hostbased}? > | | | +---u ts:local-or-truststore-public-keys-grouping > | | +-- none? empty {client-auth-none}? > | +-- ca-certs! > | | {client-auth-config-supported,sshcmn:ssh-x509-certs}? > | | +---u ts:local-or-truststore-certs-grouping > | +-- ee-certs! > | {client-auth-config-supported,sshcmn:ssh-x509-certs}? > | +---u ts:local-or-truststore-certs-grouping >=20 > On the TLS side, we have this: >=20 > +-- client-authentication! {client-auth-config-supported}? > | +-- ca-certs! {x509-certificate-auth}? > | | +---u ts:local-or-truststore-certs-grouping > | +-- ee-certs! {x509-certificate-auth}? > | | +---u ts:local-or-truststore-certs-grouping > | +-- raw-public-keys! {raw-public-key-auth}? > | | +---u ts:local-or-truststore-public-keys-grouping > | +-- psks? empty {psk-auth}? >=20 > On the HTTP side, we have this: >=20 > +-- client-authentication! {client-auth-config-supported}? > +-- users > +-- user* [user-id] > +-- user-id? string > +-- (auth-type)? > +--:(basic) > +-- basic {basic-auth}? > +-- user-id? string > +-- password? ianach:crypt-hash >=20 > What exactly is the problem? Right now, the question at hand is to what we do with the built-in = =E2=80=9Cuser=E2=80=9D lists in the SSH and HTTP server models. =20 I don=E2=80=99t use them in my application, but it seems that 1) having = something simple (e.g., htpasswd-like) might help some and 2) they can = be optionally implemented/enabled, so it doesn=E2=80=99t hurt to leave = them in. =20 I=E2=80=99m a fan for just tying up the loose ends Michal is raising, = but I thought you were advocating something else? > a) Is the issue that there is no support for keyboard-interactive in > the SSH model? There is now per this commit: = https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b= 25c0c4c518379accffcf0 = An updated draft will be posted once we get past yours and Michal's = comments.=20 > b) Is the issue that there is no support for non-local user databases > for SSH and HTTP authentication? If we think that is important, yes. The current =E2=80=9Csolution=E2=80=9D= for non-local user databases is 1) don=E2=80=99t enable = "client-auth-config-supported=E2=80=9D and 2) augment-in what is needed = for the application=E2=80=A6and maybe 3) only use TLS, where the = truststore/keystore + cert-to-name obviate the need for a user database. > Personally, I would be fine to go ahead with these limitations as long > as we have the structure in place to add things later (e.g., once > vendors have prototyped extensions paving the way to a standard > solution). Okay, I think we=E2=80=99re aligned in this regard. As mentioned above, = the various "client-authentication=E2=80=9D nodes don=E2=80=99t have to = be implemented, so more complete solutions come in the future. K. --Apple-Mail=_54FE5B1B-81E0-49D8-AE2F-E77BAF17B486 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Juergen,


On the SSH server side, we have this:

      | =  +-- users {client-auth-config-supported}?
=       |  |  +-- user* [name]
      |  | =     +-- name? =          string
      |  | =     +-- public-keys! {client-auth-publickey}?
      |  | =     |  +---u = ts:local-or-truststore-public-keys-grouping
=       |  | =     +-- password? =      ianach:crypt-hash
=       |  |     | =       {client-auth-password}?
=       |  | =     +-- hostbased! {client-auth-hostbased}?
      |  | =     |  +---u = ts:local-or-truststore-public-keys-grouping
=       |  | =     +-- none? =          empty = {client-auth-none}?
      | =  +-- ca-certs!
      | =  | =       {client-auth-config-supported,sshcmn:s= sh-x509-certs}?
      | =  |  +---u ts:local-or-truststore-certs-grouping
=       |  +-- ee-certs!
=       | =          {client-auth-config-= supported,sshcmn:ssh-x509-certs}?
=       |     +---u = ts:local-or-truststore-certs-grouping

On = the TLS side, we have this:

=       +-- client-authentication! = {client-auth-config-supported}?
=       |  +-- ca-certs! = {x509-certificate-auth}?
=       |  |  +---u = ts:local-or-truststore-certs-grouping
=       |  +-- ee-certs! = {x509-certificate-auth}?
=       |  |  +---u = ts:local-or-truststore-certs-grouping
=       |  +-- raw-public-keys! = {raw-public-key-auth}?
=       |  |  +---u = ts:local-or-truststore-public-keys-grouping
=       |  +-- psks? =             &n= bsp;empty {psk-auth}?

On the HTTP side, we = have this:

=       +-- client-authentication! = {client-auth-config-supported}?
=          +-- users
=             +-= - user* [user-id]
+-- user-id? =       string
+-- = (auth-type)?
=             &n= bsp;     +--:(basic)
=             &n= bsp;        +-- basic = {basic-auth}?
=             &n= bsp;           +-- = user-id?    string
=             &n= bsp;           +-- = password?   ianach:crypt-hash

What = exactly is the problem?

Right now, the question at hand is to what we do = with the built-in =E2=80=9Cuser=E2=80=9D lists in the SSH and HTTP = server models.  

I don=E2=80=99t = use them in my application, but it seems that 1) having something simple = (e.g., htpasswd-like) might help some and 2) they can be optionally = implemented/enabled, so it doesn=E2=80=99t hurt to leave them in. =  

I=E2=80=99m a fan for just = tying up the loose ends Michal is raising, but I thought you were = advocating something else?


a) Is the issue that there is no support for = keyboard-interactive in
  the SSH model?


An updated draft will be posted once we get past = yours and Michal's comments. 


b) Is the issue that there is no support for non-local user = databases
  for SSH and HTTP authentication?

If we = think that is important, yes.  The current =E2=80=9Csolution=E2=80=9D= for non-local user databases is 1) don=E2=80=99t enable = "client-auth-config-supported=E2=80=9D and 2) augment-in what is needed = for the application=E2=80=A6and maybe 3) only use TLS, where the = truststore/keystore + cert-to-name obviate the need for a user = database.



Personally, I would be fine to go ahead with these = limitations as long
as we have the structure in place to = add things later (e.g., once
vendors have prototyped = extensions paving the way to a standard
solution).

Okay, = I think we=E2=80=99re aligned in this regard.  As mentioned above, = the various "client-authentication=E2=80=9D nodes don=E2=80=99t have to = be implemented, so more complete solutions come in the future.


K.


= --Apple-Mail=_54FE5B1B-81E0-49D8-AE2F-E77BAF17B486-- From nobody Tue Apr 27 18:51:07 2021 Return-Path: <01000179162c2275-455b8241-396a-4737-a1cf-fbd68643352e-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 6E1E83A0DE2 for ; Tue, 27 Apr 2021 18:51:05 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 aBXcgBytQozs for ; Tue, 27 Apr 2021 18:51:03 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD383A0DDC for ; Tue, 27 Apr 2021 18:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619574661; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=HKqLZGR42tEsXiF3K7ZIZSgGSbW/pC923FuDZvi+E6Y=; b=RyPhsXsq4CvwLNfUppA1z7sTVg8ZOUDL7yp/ewbwe3CPxZzq2lUC+iiBSfUI9gnX b0mZgPZaWNAS89q+wtGwhhmK4rsEOSC/WKjuFULpYQM6ROv5HkhgbJqrhgxp/+OXnk3 0j45kPPhP+2imvq5AGZp23llMYAKBxWRLnZPY1Ks= 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 In-Reply-To: <5722-6087b500-43-4f051c00@163630813> Date: Wed, 28 Apr 2021 01:51:01 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000179162c2275-455b8241-396a-4737-a1cf-fbd68643352e-000000@email.amazonses.com> References: <5722-6087b500-43-4f051c00@163630813> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.28-54.240.8.33 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 01:51:06 -0000 Hi Michal, >> In ietf.-ssh-client: should "leaf-list submethods=E2=80=9D or = "leaf-list oids=E2=80=9D be ordered-by user? >=20 > Right, yes, I believe so. Fixed. >> RELATED: In iets-ssh-server: should any of =E2=80=9Clist submethod, = =E2=80=9Clist prompt=E2=80=9D, or "list gssapi-with-mic=E2=80=9D be = ordered-by user? >=20 > Reading through the RFCs again, I think all of these lists should = actually be user-ordered, I missed that before. Moreover, if "list = submethod" is user-ordered, the default submethod should simply be the = first one and you can remove the "leaf default-submethod". All done. Now the description on "list submethod=E2=80=9D says: "All the submethods supported for the user. If the user does not request any specific submethod, the first one will be used." >>> 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. >>=20 >> The ssh_config manage has: >>=20 >> PreferredAuthentications >> 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: >>=20 >> gssapi-with-mic,hostbased,publickey, >> keyboard-interactive,password >>=20 >> We could support this either by: >>=20 >> 1) wrap everything inside an =E2=80=9Cordered-by user=E2=80=9D list >>=20 >> 2) define a =E2=80=9CPreferredAuthentications=E2=80=9D like variable, = to provide an external ordering >>=20 >> Thoughts? >=20 > This is probably just a YANG modeling issue. I was already thinking = about 1) and it seems to me it would make for a nice configuration data, = but the YANG itself would be cluttered. Nevertheless, there may be a = clean solution I am missing so it is up to you. We have simply assigned = a priority to each authentication method, but I am not saying that is = ideal. #1 seems better at first but, assuming the list is called = =E2=80=9Cauthentication-method=E2=80=9D, the immediate issue is what the = =E2=80=9Ckey=E2=80=9D should be. We=E2=80=99d have to introduce a = somewhat artificial =E2=80=9Cname=E2=80=9D node, which makes the = approach less appealing. #2 seems easy enough: leaf-list preferred-authentications { type enumeration { enum publickey { ... } enum password { ... } enum hostbased { ... } ... } But new =E2=80=9Cenums=E2=80=9D cannot be augmented into an = =E2=80=9Cenumeration=E2=80=9D (in case that is ever desired). We could = use =E2=80=9Ctype string=E2=80=9D, but that's too open. Another option = would be to define a hierarchy of identities and then have a leaf-list = of identityrefs. This could work, but... Now I=E2=80=99m thinking to leave the order unspecified, since it=E2=80=99= s a minor optimization (saving a round-trip), as the =E2=80=9Cnone=E2=80=9D= option can be used to get a =E2=80=9Cproductive methods=E2=80=9D list = from the server. =20 You said that you=E2=80=99d did this optimization before, but did it = really matter, to save one roundtrip, especially in the context of using = the keyboard-interactive method? How about this for the the =E2=80=9Cclient-identity=E2=80=9D node=E2=80=99= s description? "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." >>>> On #3, this is likely mostly for me to resolve, but it seems to me = that *all* client-auth details should be under the =E2=80=9Cuser=E2=80=9D = 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 =E2=80=9Cproductive method = names=E2=80=9D to return to the client. Thoughts? >>>>=20 >>>> Separately, for background, I mentioned before that X.509-cert auth = is a variation of the =E2=80=9Cpublickey=E2=80=9D authentication method. = RFC 4253, Section 6.6 clearly indicates this, as it consistently says = "certificate or public key=E2=80=9D, and RFC 6187, Section-2.1 likewise = supports this. So, we could push the whole =E2=80=9Chow to support = X.509 formatted keys=E2=80=9D into/under the =E2=80=9Cpublickey=E2=80=9D = 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. >>>=20 >>> 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. >>=20 >>=20 >> If in your first question you mean an =E2=80=9CX.509-based = publickey=E2=80=9D, then yes, but... >>=20 >> - if auth happens via an "ee-cert=E2=80=9D, the ee-cert for each user = needs to be configured, but it=E2=80=99s open as to if each user points = to a specific ee-cert or if all users point to a bag of ee-certs. >>=20 >> - if auth happens via =E2=80=9Cca-cert=E2=80=9D, the same statements = apply, but there is even less affinity, as typically a CA issues many = EEs. >=20 > Yes, I understand, but I have too little experience with certificates = and practical use-cases so I am not able to decide whether the = certificate configuration can be only per-server or needs to be = per-user. This is why I wrote before that it would likely be up to me to resolve = ;) I think I=E2=80=99ll sleep on it, maybe insight will come in the = morning... >>>>>>>> BTW, this introduces an issue as to if = =E2=80=9Cclient-identity-mappings=E2=80=9D 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? >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> X.509-based auth *is* a variation of =E2=80=9Cpublickey=E2=80=9D = auth, so a =E2=80=9Cusername=E2=80=9D is still being passed in the = SSH_MSG_USERAUTH_REQUEST message... >>>>>=20 >>>>> 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? >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>>=20 >>>> Digging into RFC 6187 again, I find this jewel: >>>>=20 >>>> 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. >>>>=20 >>>> 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 = =E2=80=9Cuser name=E2=80=9D is already being passed in the base = SSH_MSG_USERAUTH_REQUEST message. >>>>=20 >>>> Popping this discussion back up to YANG models, ietf-netconf-server = current has this snippet: >>>>=20 >>>> 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? >>>> } >>>>=20 >>>> The questions are: >>>>=20 >>>> 1) are "client-identity-mappings=E2=80=9D needed at all? >>>> 2) if =E2=80=9Cyes=E2=80=9D, then do they override the base =E2=80=9C= user name=E2=80=9D value? >>>>=20 >>>> For #1, I think you=E2=80=99re saying that flexibility is good and, = for #2, RFC 6187 seems to be saying that it=E2=80=99s a matter of local = policy. Agreed? >>>=20 >>> 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. >>=20 >> Ack, and we shouldn't support a low-probability use-case. >>=20 >>=20 >>> 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. >>=20 >> I think what you are saying is: >>=20 >> 1) if a cert-to-name mapping is NOT found, then fallback to the = SSH-level username >>=20 >> 2) if a cert-to-name mapping IS found, then it SHOULD override the = SSH-level username. >=20 > If you decide to keep this mappings, I was suggesting a completely = generic solution when you could configure a specific username for the = cert-to-name mappings. >=20 > 1) If the user name is configured and > a) matches the SSH user name, you try to use the mapping and override = the SSH user name. > b) does not match the SSH user name, you ignore this mapping. > 2) If the user name is not configured, you always try to use the = mapping. >=20 > But there is still the question of what to do if you find no matching = mapping. I suppose it could be a separate configuration leaf deciding = whether you want to fall back on the SSH user name or fail the = authentication altogether. Added that mappings override the SSH-level username. Added a separate configuration leaf for if a mapping is *required* K. From nobody Tue Apr 27 22:54:02 2021 Return-Path: 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 876533A1A67 for ; Tue, 27 Apr 2021 22:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 VqW1PWMPr_kw for ; Tue, 27 Apr 2021 22:53:55 -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 8701F3A1A66 for ; Tue, 27 Apr 2021 22:53:55 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 7C32E6007D; Wed, 28 Apr 2021 07:53:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619589232; bh=FKnrFfUMy/Yaw7u/bZhSlovj19HNHZrmuyz85gl/gTs=; h=From:In-Reply-To:Date:Cc:To:Subject; b=PdWDNN7w+vJvmkcVGmGDrtu+YXuj5zbI0maEjPN94AgpOc/5lsH/UwJqCRm6KruAG C+ZO3beDgtizEMHmtGJ5wDJ/+cBP1rAIPQX1miEL4h7PyXU20oqdVVhHuWXq4CHDJd La94qBzXj9M2JefA9u47pLywNappvcJGzzKEvMhg= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <01000179162c2275-455b8241-396a-4737-a1cf-fbd68643352e-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Wed, 28 Apr 2021 07:53:52 +0200 Cc: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <7e27-6088f880-ab-5a394d00@108443239> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 05:54:01 -0000 Hi Kent, starting with the issue of the exact purpose of all these modules, I ma= y have misunderstood. It seemed to me they are meant to fully configure= an SSH server/client, NETCONF server/client, ... With the limitation o= f leaving out some rare or too complex use-cases up to augments. At lea= st that is what I was trying to help you with, but these criteria are s= ubjective, of course. Still, I think we are pretty close now, from my perspective. As was dis= cussed, the "keyboard-interactive" method is a completely generic one w= here the user is presented with a set of challenges and must correctly = respond to them to pass the authentication. That should already work an= d the issue I was trying to solve is a security one, when the expected = response is some sensitive information. Adding that, I think the config= uration would be able to (safely) express all configurations that do no= t require any additional information (such as, I don't know, retrieving= the expected response from some remote server). Incidentally, the expe= cted response of the user password would also be supported. More below. > >> The ssh=5Fconfig manage has: > >> > >> PreferredAuthentications > >> Specifies the order in which the client should try auth= entication 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 > >> > >> We could support this either by: > >> > >> 1) wrap everything inside an =E2=80=9Cordered-by user=E2=80=9D lis= t > >> > >> 2) define a =E2=80=9CPreferredAuthentications=E2=80=9D like variab= le, to provide an external ordering > >> > >> Thoughts? > > > > This is probably just a YANG modeling issue. I was already thinking= about 1) and it seems to me it would make for a nice configuration dat= a, but the YANG itself would be cluttered. Nevertheless, there may be a= clean solution I am missing so it is up to you. We have simply assigne= d a priority to each authentication method, but I am not saying that is= ideal. > > #1 seems better at first but, assuming the list is called =E2=80=9Cau= thentication-method=E2=80=9D, the immediate issue is what the =E2=80=9C= key=E2=80=9D should be. We=E2=80=99d have to introduce a somewhat arti= ficial =E2=80=9Cname=E2=80=9D node, which makes the approach less appea= ling. > > #2 seems easy enough: > > leaf-list preferred-authentications { > type enumeration { > enum publickey { ... } > enum password { ... } > enum hostbased { ... } > ... > } > > But new =E2=80=9Cenums=E2=80=9D cannot be augmented into an =E2=80=9C= enumeration=E2=80=9D (in case that is ever desired). We could use =E2=80= =9Ctype string=E2=80=9D, but that's too open. Another option would be = to define a hierarchy of identities and then have a leaf-list of identi= tyrefs. This could work, but... > > Now I=E2=80=99m thinking to leave the order unspecified, since it=E2=80= =99s a minor optimization (saving a round-trip), as the =E2=80=9Cnone=E2= =80=9D option can be used to get a =E2=80=9Cproductive methods=E2=80=9D= list from the server. > > You said that you=E2=80=99d did this optimization before, but did it = really matter, to save one roundtrip, especially in the context of usin= g the keyboard-interactive method? > > How about this for the the =E2=80=9Cclient-identity=E2=80=9D node=E2=80= =99s description? > > "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." Like I said, the best example of a problem we were solving with these p= riorities was that when your SSH client has both "publickey" and "passw= ord" authentications supported and working and you connect to an SSH se= rver that supports the "publickey" authentication, it is probably the m= ethod you prefer. I may be missing something but how do you solve this = problem without some way of expressing these priorities explicitly? I d= o not see how getting the supported methods from the server will help y= ou, it is strictly up to the client which of the methods it will select= next (first). > >>> For #1 I came up with a possible scenario when the "client-identi= ty-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. > >> > >> Ack, and we shouldn't support a low-probability use-case. > >> > >> > >>> 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. > >> > >> I think what you are saying is: > >> > >> 1) if a cert-to-name mapping is NOT found, then fallback to the SS= H-level username > >> > >> 2) if a cert-to-name mapping IS found, then it SHOULD override the= SSH-level username. > > > > If you decide to keep this mappings, I was suggesting a completely = generic solution when you could configure a specific username for the c= ert-to-name mappings. > > > > 1) If the user name is configured and > > a) matches the SSH user name, you try to use the mapping and overri= de the SSH user name. > > b) does not match the SSH user name, you ignore this mapping. > > > 2) If the user name is not configured, you always try to use the ma= pping. > > > > But there is still the question of what to do if you find no matchi= ng mapping. I suppose it could be a separate configuration leaf decidin= g whether you want to fall back on the SSH user name or fail the authen= tication altogether. > > Added that mappings override the SSH-level username. > > Added a separate configuration leaf for if a mapping is *required* So you have decided to keep it? In any case, its functionality should n= ow be unambiguous. Regards, Michal From nobody Wed Apr 28 00:11:26 2021 Return-Path: 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 1D0B13A1D6A for ; Wed, 28 Apr 2021 00:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 EDoNP1Wnkagb for ; Wed, 28 Apr 2021 00:11:20 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20042.outbound.protection.outlook.com [40.107.2.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB053A1D75 for ; Wed, 28 Apr 2021 00:11:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q0/Gs9FBxi/ZT1qibSRHwjWTWr7uHKIqiDnOa2jQtWdG2Tzppvsqof/Gz65popqB+zT4VR0NIax1aHHB+HZlmO4Npfa8S8pDwd35M4GiDbGZUOZ4GY9NFaJIzLdIJhxiGzfDG9TQ7+TX5cWXQ8yMobqraeI5Ja2jv+GrgiE+1IR1FG/erp7ou6VML4d7IddQUhiGu7i4gouwpqpKzuAQ6jpOVPAUKSmyMeLH/rzZTNwbXPsVcoblXMCuFPwTWHP1m8DDaOuk2T67y6oNalZa2v3dMysc9u25/ndZYF6UL8IiwiuE3zoNBfUrZkC04mN5MWit63EyoTDpR4WJkswXVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kZ2Mrs0YNHK1Lkl9a3nA3BzVF1JFemcrKUkjinv3I48=; b=VGD1l+ZCVevRt+0ho+XwjuEpcy/GK1hjk5Q0n2za/QLev4K9nAcZWt7ROzNIIyv3EWyc7pc3XLfrQqoWt7F7uSM2xNNDwe7vhNAc0pbWBDG58MBI6epMJ0gs7Jx2wrQZUG4kT0ktNe59xAZ9WsZF4pOXUIL3RXpCDQAaAEIMWYUkz8XXXJuxErsKCscpLNkWr0kDrWX/YlVqwhTDjfbe6BIIp3x3AECW3WvVy2sTMkXzjsJWwdn5omR+gfFcNBirbXYk3P3/e/wal4vN0mAEIx4z2nTGfmzWQfBvn9Kz75ltj7IJcjk9/XcB9Tft2gsgwzw5exnG2CvHwdh1XklG/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kZ2Mrs0YNHK1Lkl9a3nA3BzVF1JFemcrKUkjinv3I48=; b=lAlJTPDw6exO4Za2k9dCByWZsxNWktjCg5mhkZUhhatyEe0as5JKkbNGsDeLMSjrIsrUxCivLpmFSXphqMEJ0IPerN55+AO0Ix2UGSC6Km6X6UG03Xt27Gm9bX9KT8YZEPBAjFam9O3J5JZdJvIPlCpgCTF8PkNJfVTNrmGYo0w= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0756.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Wed, 28 Apr 2021 07:11:17 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4087.026; Wed, 28 Apr 2021 07:11:17 +0000 Date: Wed, 28 Apr 2021 09:11:16 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: Michal =?utf-8?B?VmHFoWtv?= , "netconf@ietf.org" Message-ID: <20210428071116.33uc3m2vzo5gq6lf@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Michal =?utf-8?B?VmHFoWtv?= , "netconf@ietf.org" References: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> <78fd-6087b600-7b-59cd2c00@214199368> <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de> <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@email.amazonses.com> <20210427155544.pd7bmt2hdztx2zui@anna.jacobs.jacobs-university.de> <0100017914bb076f-9fb97a64-b35a-474d-9222-9be5ec784aaf-000000@email.amazonses.com> <20210427210046.gtfcwwf5kefxfme5@anna.jacobs.jacobs-university.de> <01000179158224da-a7663485-0b99-42b8-b85d-804c9d17ec5f-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01000179158224da-a7663485-0b99-42b8-b85d-804c9d17ec5f-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR3P195CA0003.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::8) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P195CA0003.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.27 via Frontend Transport; Wed, 28 Apr 2021 07:11:17 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4ee2fba6-4cec-4a86-d42d-08d90a14d0f3 X-MS-TrafficTypeDiagnostic: AM0P190MB0756: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2657; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pwUXV7M+M6q6Sc3VoLN7aAjoHaYo3nUy4VOeAYH4QJNHllFLWyuHbVc/uWSzZUiCv6aAzgfmL8FURcmcccZSi4WkH65um7WVG5Bx32zm3jNStfeqyC5VvD2qB8uJ9657upXFzJUClnMUYXgC+m7qznVlGYO00BFKbpt50/Ydgp0IZzjmOhgEAqch7Elyw8WSnf1o8SNPY25gJq81Ajsi4ddn0SXXVuYnPbbrsIlTS08cMgkjgQ01bDemV6VCJFTrGhx4LZm9nUIwhcz+/x2eJ+Dq9xPv0cF32QVoFgV4cAmgTTeiGp71wAseyzT2x5HbqFcJezyNgQs2gZCA0BXOlssVvaReo8NbORcQlOpb26fb7mBfq/ricOeUGw9B+0rl2D92yyxM0SRy1ed/JiwxGFOhw+5mc8zgkJoNbZn5qVA6Lvm32n3TWFyNa4/NXYHq4Nf4ECWyXe5GZ4Y579IP6SRmotYrSK8aGpZT7SNtD5oe6GO7syTF6xkWCXE+rhJQRW52HrCWRLgK0lwS/hIw2qMK9YMW/XjV97Udh3w9+7Pe4Qc3nlwcyFew5jMGmng7iRE0bxr9JTtKn7Jk3125HDWQR+Voai82+Ewjve1ZeH3c+CW5ZXxjV4+0z5yHvouPcfHYvH4b69L9c0eqPQfKbh6FGQocm392lCjnyUefHDq8+8idcvpxd3mFm8BqKh53BAEBO+QmdkDjEuIYKJio0H/9CI0Sg4WOgEXbrTpHGioXMfMobf4p0grd27XaRech X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(376002)(39850400004)(136003)(366004)(396003)(6496006)(26005)(16526019)(186003)(83380400001)(2906002)(6486002)(66946007)(38350700002)(3450700001)(38100700002)(66476007)(66556008)(52116002)(956004)(8936002)(1076003)(5660300002)(86362001)(4326008)(316002)(786003)(478600001)(966005)(8676002)(54906003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?anRkamlsYXBtYWRxVm1tR21EaHVqSXhWcTJjZkdhQ0l6VENoUldCa1lrRWRu?= =?utf-8?B?NDNpd0llZnFaTG9keEpjbEVUT3ZrUzNNeWZPUGNzK3JWWVIxMFo2LzNvcDdh?= =?utf-8?B?dHZCeFp3ajBlZlJGMWROeHdtOENxa2tzV1plWVBKdTk5RGlFTEg0L1I0MURM?= =?utf-8?B?OWNiNTE4dmMrNFdzczZLTVJLUjJGaTJQSG1jQU9nMWhtUEk2ak9lR1c1TmRX?= =?utf-8?B?bSt2ZEhzUlRpVllyQkpwMWN1TjNZOStFTkR3WEsrR1c5TTd6bEhjZExpTEhx?= =?utf-8?B?VTB3aG5BMHBGUzJqOTFZTUtiTDhTTTBBb0ZjZXBHWnJYY3pibHlpU0hPS1Br?= =?utf-8?B?ZTlsc0x0T2YxWWd1ejkwWXcwakRqdkNGaUQyUUZ3YWJSQTlMUTF2MjRFckhX?= =?utf-8?B?MUFyTnhsZlB6bzJlRUNOTUR2SjdRTzRjWUorV2dPVUNtLzhXL2NnSDlidW5X?= =?utf-8?B?WGpYbERubG1rNnhlUEJjLzQwTzI5NHA0RVJjY1p4bHhkbkFVN3RTVE03MkNI?= =?utf-8?B?bFltdGdPSUd1dzE3bTF1OEs5REFNMDVweXYxZi9kMXhVOHpXd2pjeU9IV0R4?= =?utf-8?B?MkNveEVoQ1Q3YmFmRSsxR2huSGErTEN2OWJIcnQ1aDVNYVB3T2YvQld0UlFZ?= =?utf-8?B?RFRQUUlhTWhleXNlRllER3dRRys0YkJYMkpneDIrUVo0VUE4SzNBaVRsanpm?= =?utf-8?B?SGhkUXo1M3Z0anoyWldFOWtybCtzeFRvOEdIRzhNSXJUOEgraTUyblJzTkFZ?= =?utf-8?B?R2tZRlhrbHBPbXBsYjBvZzZmZ2t0UUpsR3RoZ2xtWXRqZjZDN1FWYmoySW9p?= =?utf-8?B?a2xqZ0t4UnRJRW1QQ1dYcUJiSys4eDJCRStDM2drRjBDenhPcjdueTAwQ0wy?= =?utf-8?B?K3g5SDkwOUJIRXV3aVFiT0RyWllNbWxXQUl6VmlBS1hCUWgrZXgyTmpMOEY2?= =?utf-8?B?QzU5TEsxN0hnWURJOFpQNkdzb3ZzTCtVSmd3c25TdTFqR0NWSDF3ZVUvK1RB?= =?utf-8?B?L2xVODVQalo5MHc5eXZFbDdsWkl0N2ZrRnRxMEN5WFpnblA1TGl3STJXcGEx?= =?utf-8?B?d2x5eTlKTWRtM3F1VjAvck5oV0NUSWsrUS9CUTdBMHVGMmw5aHRUbjVRQlZ6?= =?utf-8?B?cG0zV0c2N0RFNUNxRXNDUFdiYXJBM050MzY3aGZLeklFWVZ2TElUZHVnWThy?= =?utf-8?B?T1R5bHBSUFRISVIreVQ5TVBmWjFaVmhxQzVISi9PaktTY2tYU1NER3dGMUFX?= =?utf-8?B?TExBU1lFa1RrNVdUU2FZaEhkMHp3dmNhWk8yaEFpRSs2VW12UVF6S0wrbG56?= =?utf-8?B?RWZMMVo1L3UwcDdLek1KU3VHWGJKTk9xUEU3K0Q0SnRydkJySkVhb3pNVXBz?= =?utf-8?B?Uy9UdlJJVk00VmM2TDFUdWgrVTBiSUdYY05ETFJmZEtPVE1wRisyWXV5TFlH?= =?utf-8?B?L2N0SXNKeG44alZxdHVLMUJaeEwxc0lLbHpiS0Q1SDE1K2FuWUQ1bFJyRVBi?= =?utf-8?B?MEFkZEFyZE5JTFlSeS8xck9pcVVid2R1TzB3cW4xNWNrZDlqeTZoWU5iVzIy?= =?utf-8?B?ZW1ycG5FZ2tPQ29zV1ZNQnBtTFNPVmtPVmxqQ1dCU2d3T3VmcXdpNVg3dVhL?= =?utf-8?B?SWFTMHZhZGEyczBYaERCUDY3c2JDejNqN2J0dVI5eVk3RUpBWGZxUnVUb0pX?= =?utf-8?B?Q3p6L3Q0dUhtaStvRUYwNXhRS0w2MG1nenlUbWQ1cFZ1eTNLd1hJYmlSckdB?= =?utf-8?Q?vrIIOOSbi2MwjH4R7URrQrn8mN29n0VfxLCH0kc?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 4ee2fba6-4cec-4a86-d42d-08d90a14d0f3 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2021 07:11:17.2234 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dhNnnwqv6bX9PtiBma2j+Qm2cjTEJ/lP8W//O11zCbxUpxhdNdSVtoEvcM3uDF/akK3p7CF9yRQgIfMS3xJAeA8vVsvmdCkIc+3xQI5crz4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0756 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 07:11:25 -0000 On Tue, Apr 27, 2021 at 10:45:21PM +0000, Kent Watsen wrote: > > I’m a fan for just tying up the loose ends Michal is raising, but I thought you were advocating something else? > I am not advocating anything. I just tried to clarify that keyboard-interactive is a complex authentication mechanism to model since you have to model some of the functionality of PAM for it. If you enable keyboard-interactive in your sshd config, you are essentially saying "go and read the PAM configuration to figure out what will happen". > > a) Is the issue that there is no support for keyboard-interactive in > > the SSH model? > > There is now per this commit: https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0 > To me this makes little sense, you are not done by statically configuring challenges and responses, this is from my view really missing the point of keyboard interactive. I am sure you can write a PAM module that does that but the value of keyboard is not this kind of trivial configuration. My point is that if we model keyboard-interactive, we have to get it right, which is complex. Hence my suggestion is to not model it at this point in time. I also stumbled over "A list of locally configured users (i.e., SSH clients)."; For me, an SSH client and a locally configured user are very different things. For me, the SSH client is the piece of code running on the client side, the user is an account on the remote system. > > > > b) Is the issue that there is no support for non-local user databases > > for SSH and HTTP authentication? > > If we think that is important, yes. The current “solution” for non-local user databases is 1) don’t enable "client-auth-config-supported” and 2) augment-in what is needed for the application…and maybe 3) only use TLS, where the truststore/keystore + cert-to-name obviate the need for a user database. > Well, you can configure SSH user authentication mechanism to reach out to RADIUS or Kerberos or Diameter or ... RFC 7317 does support the RADIUS backend option. Having to augment in new trees to support lets say RADIUS is somewhat expensive. (I _assume_ you can call out to RADIUS from the SSH password authentication method, i.e., this may not require to have keyboard-interactive.) But perhaps also this can be dealt with once there is more implementation experience. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 28 00:23:20 2021 Return-Path: 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 17C963A1DCE for ; Wed, 28 Apr 2021 00:23:18 -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 7O-rAAUqnVLu for ; Wed, 28 Apr 2021 00:23:12 -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 ABF9A3A1DCB for ; Wed, 28 Apr 2021 00:23:11 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 5B1D66007E; Wed, 28 Apr 2021 09:23:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619594589; bh=DCKq9Wx1gN9zM3GJeb9AC5HrGD3B/6/IGXqSePCB/nU=; h=From:In-Reply-To:Date:Cc:To:Subject; b=wTp8vDoE7Rbe59yq32pocTEAPD60nkSejbYGsud3QGZOTfHAcFSc/xwP3EQ6Mxafz VC/6J9Vm7Zl5UIagpS1MGF/faqEYWpLRaBXttz0Ia/v/8kv2FzQAepMDDuig+IvbfR 5mWLmkc7N3Z2ON1RY7pRf7p9tJxtjnvTKr6hKPFs= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <20210428071116.33uc3m2vzo5gq6lf@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Wed, 28 Apr 2021 09:23:09 +0200 Cc: "Kent Watsen" , =?utf-8?q?netconf=40ietf.org?= To: "Juergen Schoenwaelder" MIME-Version: 1.0 Message-ID: <38a8-60890d80-47-ca98650@116585071> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 07:23:18 -0000 Hi Juergen, I tried to explain below that your understanding of the configuration m= eaning is wrong, let Kent correct me if it is me who got it wrong. > On Tue, Apr 27, 2021 at 10:45:21PM +0000, Kent Watsen wrote: > > > > I=E2=80=99m a fan for just tying up the loose ends Michal is raisin= g, but I thought you were advocating something else? > > > > I am not advocating anything. I just tried to clarify that > keyboard-interactive is a complex authentication mechanism to model > since you have to model some of the functionality of PAM for it. If > you enable keyboard-interactive in your sshd config, you are > essentially saying "go and read the PAM configuration to figure out > what will happen". That is specific to sshd and is supported in the modules if you disable= "client-auth-config-supported". But if you enable it, you want to conf= igure the authentication yourself, in the module. > > > a) Is the issue that there is no support for keyboard-interactive= in > > > the SSH model? > > > > There is now per this commit: https://github.com/netconf-wg/ssh-cli= ent-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0 > > > > To me this makes little sense, you are not done by statically > configuring challenges and responses, this is from my view really > missing the point of keyboard interactive. I am sure you can write > a PAM module that does that but the value of keyboard is not this > kind of trivial configuration. Reading the RFC that defines this method, I think it models it exactly = the way it is defined. Please ignore PAM, it is not used if this config= uration is in-effect. > My point is that if we model keyboard-interactive, we have to get it > right, which is complex. Hence my suggestion is to not model it at th= is > point in time. It seems fairly straightforward, from its definition. > I also stumbled over > > "A list of locally configured users (i.e., SSH clients)."; > > For me, an SSH client and a locally configured user are very differen= t > things. For me, the SSH client is the piece of code running on the > client side, the user is an account on the remote system. Again, the point of having "client-auth-config-supported" enabled is th= at you do not read the authentication information from the system and i= gnore any 'accounts on the remote system'. Instead, you configure the a= llowed users yourself. > > > > > > > b) Is the issue that there is no support for non-local user datab= ases > > > for SSH and HTTP authentication? > > > > If we think that is important, yes. The current =E2=80=9Csolution=E2= =80=9D for non-local user databases is 1) don=E2=80=99t enable "client-= auth-config-supported=E2=80=9D and 2) augment-in what is needed for the= application=E2=80=A6and maybe 3) only use TLS, where the truststore/ke= ystore + cert-to-name obviate the need for a user database. > > > > Well, you can configure SSH user authentication mechanism to reach ou= t > to RADIUS or Kerberos or Diameter or ... RFC 7317 does support the > RADIUS backend option. Having to augment in new trees to support lets= > say RADIUS is somewhat expensive. (I =5Fassume=5F you can call out to= > RADIUS from the SSH password authentication method, i.e., this may no= t > require to have keyboard-interactive.) But perhaps also this can be > dealt with once there is more implementation experience. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > Fax: +49 421 200 3103 From nobody Wed Apr 28 00:38:51 2021 Return-Path: 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 B40303A1E4F for ; Wed, 28 Apr 2021 00:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 yKOmME58tXT8 for ; Wed, 28 Apr 2021 00:38:44 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2059.outbound.protection.outlook.com [40.107.21.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326A93A1E4E for ; Wed, 28 Apr 2021 00:38:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S8jr+/lwDrs3m9brQIXZSa33BYIA5Atz6hcAcXnc5Aky+alfhGASI6++F96BTRYsaMUqZg3uD3Qs8Mn+Sp3dhEQduB9MD3D0gwCqPMcFI1GlM38T+LAMYVNefq62GItHsG8ypieFeVV0v9SuOB/FWnuic4Y7dgKGncoikYUv/jAyFW6twQ2W7YlW5+TkSX6yCy4jwEvUq3IE4sHKTmWUjVeDfrA6iA8M02ehWdBWTW72NDB80j4nRf1ennZvQixQWPm4eqg7SiHrOFyd/zzDhqAw2zsQKP+11VnNpXj8QikgxuX2pe0F6tbug+1Q1H+k7IUnitw6aBw7JyTybev9tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yeuiG21LAwulsAsYQKIt9YeSgtcvQax/0KQAiD7FFdE=; b=edF30tU/wUqZfX7WBvzhxkDjuFrtVuCWzQwjVoMYpiF6wizqAK/3JcoQB8FKESMjMp8XqJ1kBREOlABAL+1L09+hwjloPGPliO+U7aKkEK8gfP3JR556gTDOQBgGglS3YcEtoFXCMbuYnxmT/FZupHphItjNQf1DV/iP9zyN+b28yYQxcp8Ys0o3Q5/oYs3e/GCb6jux/E8uBygXBcJ5YbPG771fC7yAK580ZIFHJpGaD24uHy9SXsO/cqm1AWAaDhks/CPtBHDlxki8Xkzie7xccHpwLhGCUL4GvVoBBNLN4dSmX7TSOCkqTsM5CiSjCrS2p7pssqfgUHAfjufQVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yeuiG21LAwulsAsYQKIt9YeSgtcvQax/0KQAiD7FFdE=; b=LSnRMgf67Ty5d5TRk3HRcpK15+EK3GON7Ig5O64aqB/sbEOpb1ErDVvXkmX5FWoPQZrjIR0hMCihg7Kj8oFDxnJs+NDaDWckb19qAnEZT9O1Xebho8lbXKpxitvYTtJNR4rSOlkdC4DO82oUCQp4Q+Ly3wuBRw9fuBRVh+g38DE= Authentication-Results: cesnet.cz; dkim=none (message not signed) header.d=none;cesnet.cz; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1618.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3b4::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Wed, 28 Apr 2021 07:38:41 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4087.026; Wed, 28 Apr 2021 07:38:41 +0000 Date: Wed, 28 Apr 2021 09:38:39 +0200 From: Juergen Schoenwaelder To: Michal =?utf-8?B?VmHFoWtv?= Cc: Kent Watsen , "netconf@ietf.org" Message-ID: <20210428073839.t5a4pdjqvvaholkp@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michal =?utf-8?B?VmHFoWtv?= , Kent Watsen , "netconf@ietf.org" References: <20210428071116.33uc3m2vzo5gq6lf@anna.jacobs.jacobs-university.de> <38a8-60890d80-47-ca98650@116585071> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <38a8-60890d80-47-ca98650@116585071> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR1PR01CA0006.eurprd01.prod.exchangelabs.com (2603:10a6:102::19) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR1PR01CA0006.eurprd01.prod.exchangelabs.com (2603:10a6:102::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.25 via Frontend Transport; Wed, 28 Apr 2021 07:38:41 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 423a5a88-472c-4fa0-49ea-08d90a18a4e6 X-MS-TrafficTypeDiagnostic: AM9P190MB1618: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1824; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1BsN5x/fe3tQbcVe9o6dli2Ea5XYaj5EnLuOZMYUBt3bJ5DJtK/04OGZGNAbOfvCXZO+cj//VhwWNLpsdmgtH81Gsg40KT15ydyQA2kLUqvqhyR8+wzW8U8gJnbd+fBTYhGLRkAHtGbqHhleA15b2YnyYqmXOMbZN4VlrrA+24EN+QJLVKh0WJYX6BwJFh7c12XbYTwkJMlgc+dLzMaeGIMpT/gXjcLWueoyYL9fK4dcewfv74hzSqfsKpJIJZGzUQo/eY41+JHcKxAgYwqIYGHJrv//kg+zGSEAUqdDJmPGyVbGxSf+1e9YHudrVVsZfCmIfUYmQHwYRlhRDPm7j2YVb2dzpxIFG/k3u6qZCslMfsdUAZ+Trnv3r2F5B5g0DQ9Vdf81S1pXKlqvOzfAbW7niIyWAbxyFp608XPR76w3hzdVeTZeL7T/kh6NmMqHmH6t8BG8jGza1soTAKM59TIUOcGMtXbLzPEpgfKKXIThBCGdiUFBvl8WZtGChoSqEEzIAnJiNNFJjk3rC0NL3uzm5Vwxin03aZhXBhDfR72mb6Obl3AV8aPwqzuLNIonF3snA38QvMH0SG8bQR3G853qj6uLTSJ4UbfN0a6r1Be+eUHnI2x4UYhVV4r1mWKt3EM1wVBndLjvDLVFgXDZaVcmS3jHdj6EAqMGJ96ypQ9+Fks1ofCMHn5O2ZzSE98ZiHQasfwq/JQyxXSRKZAGDfcL8Upe70+P+cjb79XFpKKJAmZZQguqwssDwQoJ+GWK X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(136003)(346002)(366004)(396003)(39850400004)(52116002)(478600001)(26005)(86362001)(83380400001)(6496006)(4326008)(5660300002)(3450700001)(786003)(316002)(186003)(2906002)(16526019)(38100700002)(8676002)(956004)(38350700002)(66946007)(66476007)(8936002)(66556008)(1076003)(54906003)(66574015)(6916009)(6486002)(966005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?VVQzTjFFR2ZEM1BQUE5YOFlqang2dEZDYnovUm5tWTNnUjdnQnpoMWIxeElZ?= =?utf-8?B?TFNGV2hlMUZtb3lsU2I1ME9xSkZmZVRObVZrZ28rSWlxWm1JY2t0ZGNITVY2?= =?utf-8?B?MUFOTGxXMjhlOFpyYzlINzhFaWNyOHVrekhSbldjR25sN09laDVHSFhLcHhz?= =?utf-8?B?dkkxbExkeE13d1ZWbUlwMEJ4SGtwaGFwWkt3VVVwazFRV1ZuVDMvYTlORUZU?= =?utf-8?B?NGtzNjRac3NTNXhvak5Ydm04WkVWeE1XT20xT1RNblZ0VnpBV3JxaHdjaEE1?= =?utf-8?B?ZENBTWhGNVFmeTduK1BCa1FyWm5CRGt6bWJsVTlBUnFManRJQnI4aXdRaWxv?= =?utf-8?B?Qmx3d2pXamN2L2dJc3p1ZFhLRlRsdi9FUHZJOS9IRjFiOVJWMXVqZmlwaVVL?= =?utf-8?B?Y1FqK0VkYTFHaUZMaW9tamd6bmRaWHlDTGo2OG92Ukd5dWg4am5lMHNBSUJL?= =?utf-8?B?bVhrVURKVXFOQjl4TXhWb2d5aE95SVdOdG41OHkxUTQxZGV4aWdFUDF5RE5P?= =?utf-8?B?SkpMWDMrb2k5aDFOdVhRUDdWNFROWGwwV291WTZsTkU2ZTR3OEovc2FHWkpn?= =?utf-8?B?QVhObXJ5Q0hLRnVnWWhwUUZZUWY0TU9SdGp5T0NLK2lKSUdwa3E2bWdrZFNh?= =?utf-8?B?Rzk5UG9CZjE0NHpHWFBoSUxJODJ2ZVFselVDR3JxRkZNNnFaNi9zeXdheTFD?= =?utf-8?B?TXYrNXQyWE1PS2tLUG1mY2VnODF1TWcxQzg5TG5mMElicXFmQkRUTlFqRE5j?= =?utf-8?B?OTdKcTNtSmR0ZkFUcWJVc3lVMS8zblRXd2pHSC81cDAyay9NQVcxUktwRmRu?= =?utf-8?B?b1I0SHRaMUdvQnNXdGE5ZG82dUdkWG4xUERhN2lRRzNBRnM5OTVPRWtBRE4w?= =?utf-8?B?ajhoOUdnSEZ2dUpKckJCZ0txVUtXb1RINXBZN3V2eVBaZHZuR01sSHNVMUZ6?= =?utf-8?B?eXEvSDVKMFV6Zk1nOUFqWmpMekJUNVg0SjIwYmVQdVZia3BKSmZ5VVZCcFRr?= =?utf-8?B?enluUGdIWHZuM2UwN0RQR2pKRDduNWJSL0RwMmpwdU1BamFzZzNBNEM0TzdS?= =?utf-8?B?TnNMMXQyWk5LS0Z4N3BEczZDSkY2Q0wyVktuVlhQOEZ2ZmFvUENTay9VUFlL?= =?utf-8?B?TDIvVmlJVEdBU0N2b0JneGE1Z3lhWVg4Y1pEcTE2TGdTYjRleTl6eDdtU3la?= =?utf-8?B?Z3pRR05Eb2duVFNvN0NuNHhsYU9hQTVZOEkzOS9QaEhEcmQ2MkhsWVU3UFlD?= =?utf-8?B?dUhpSXZKMFJYU2ZmUDM0RlFBUlQyc2ZrR3lpcEhrVVJlVnI1SlduQ0w0NGta?= =?utf-8?B?bWdWcjNydG4wUXc2MU0ySUxaemE5WHpqTlhKaTM0b3hvaWo0eE9kN0s2alZ1?= =?utf-8?B?aW42MStwZ0xOU3pWN3VWTk52L3RlODBMRXFDYXJhRHhlNEZBMGJkSzZSanZm?= =?utf-8?B?Y01VeVdDVUxvUTloRFBWc043UVhDNXNNeXVLRFQvYmVGMmJzVnJNZFhheVZa?= =?utf-8?B?NnpqWC8xczhmeGlxMzR3NDlubHlVdkNpWnpNQVJYRmdmeXhLbmZWMk44ajBo?= =?utf-8?B?M3hUenJpWVlRYmN6TWZMeGpHa0FxaVFDS2N4d2VkK0xSV1lSNW9SUjJDeW5n?= =?utf-8?B?amwxNGMyM2xLVVNUVk50ZkhpWi9OOHA4d1E2V09RVmZkYVlHUUs3SUpBWlFZ?= =?utf-8?B?RUNPemc3WDZTNnVaQlY5NjhST2ZHSFBtczlzTjBLWVBZS002bDhPZWZKazZm?= =?utf-8?Q?uhHmKq+W6UFRZYotNq3xiE0WuU1ctPelFwR3m79?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 423a5a88-472c-4fa0-49ea-08d90a18a4e6 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2021 07:38:41.2849 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0Y8TQRXPaP8ob1JfP7B+tP9bGqpNfXlkwA6UwK10yOYvCEe822XI2V3u6+kj79b90pbFXorDzkfMCNMIzUnXEaEnBGuvED29pOEVYq5ZFLE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1618 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 07:38:50 -0000 Let me quote from RFC 4256: [...] The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). [...] The major goal of this method is to allow the SSH client to have little or no knowledge of the specifics of the underlying authentication mechanism(s) used by the SSH server. This will allow the server to arbitrarily select or change the underlying authentication mechanism(s) without having to update client code. The name for this authentication method is "keyboard-interactive". If we model something as keyboard-interactive, it can't be a list of static strings to justify that name. My reading is that the SSH protocol talks about users. Whether these users map to system level accounts (as they would do with a regular sshd) or to some notion of 'virtual' users (on a system that shields the system behind a NETCONF server) is I believe an implementation choice. /js On Wed, Apr 28, 2021 at 09:23:09AM +0200, Michal Vaško wrote: > Hi Juergen, > I tried to explain below that your understanding of the configuration meaning is wrong, let Kent correct me if it is me who got it wrong. > > > On Tue, Apr 27, 2021 at 10:45:21PM +0000, Kent Watsen wrote: > > > > > > I’m a fan for just tying up the loose ends Michal is raising, but I thought you were advocating something else? > > > > > > > I am not advocating anything. I just tried to clarify that > > keyboard-interactive is a complex authentication mechanism to model > > since you have to model some of the functionality of PAM for it. If > > you enable keyboard-interactive in your sshd config, you are > > essentially saying "go and read the PAM configuration to figure out > > what will happen". > > That is specific to sshd and is supported in the modules if you disable "client-auth-config-supported". But if you enable it, you want to configure the authentication yourself, in the module. > > > > > a) Is the issue that there is no support for keyboard-interactive in > > > > the SSH model? > > > > > > There is now per this commit: https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b25c0c4c518379accffcf0 > > > > > > > To me this makes little sense, you are not done by statically > > configuring challenges and responses, this is from my view really > > missing the point of keyboard interactive. I am sure you can write > > a PAM module that does that but the value of keyboard is not this > > kind of trivial configuration. > > Reading the RFC that defines this method, I think it models it exactly the way it is defined. Please ignore PAM, it is not used if this configuration is in-effect. > > > My point is that if we model keyboard-interactive, we have to get it > > right, which is complex. Hence my suggestion is to not model it at this > > point in time. > > It seems fairly straightforward, from its definition. > > > I also stumbled over > > > > "A list of locally configured users (i.e., SSH clients)."; > > > > For me, an SSH client and a locally configured user are very different > > things. For me, the SSH client is the piece of code running on the > > client side, the user is an account on the remote system. > > Again, the point of having "client-auth-config-supported" enabled is that you do not read the authentication information from the system and ignore any 'accounts on the remote system'. Instead, you configure the allowed users yourself. > > > > > > > > > > > b) Is the issue that there is no support for non-local user databases > > > > for SSH and HTTP authentication? > > > > > > If we think that is important, yes. The current “solution” for non-local user databases is 1) don’t enable "client-auth-config-supported” and 2) augment-in what is needed for the application…and maybe 3) only use TLS, where the truststore/keystore + cert-to-name obviate the need for a user database. > > > > > > > Well, you can configure SSH user authentication mechanism to reach out > > to RADIUS or Kerberos or Diameter or ... RFC 7317 does support the > > RADIUS backend option. Having to augment in new trees to support lets > > say RADIUS is somewhat expensive. (I _assume_ you can call out to > > RADIUS from the SSH password authentication method, i.e., this may not > > require to have keyboard-interactive.) But perhaps also this can be > > dealt with once there is more implementation experience. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 28 15:19:06 2021 Return-Path: <010001791a9063c8-c7d5b566-f0d1-4606-a978-2e2d183284d7-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 CD4533A22AE for ; Wed, 28 Apr 2021 15:19:04 -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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 QM7YtNAMIW6G for ; Wed, 28 Apr 2021 15:19:02 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694853A22AD for ; Wed, 28 Apr 2021 15:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619648341; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=9jYpDn7l/+eYTfHvcS8sxp4GIc9FZFugyDvENH6hG7I=; b=O0n0jNW7DjViQy90CU5UJYFNtfr9rxzbE72jS6ZXWVdj92N4zdJyirE4AzQXtXRJ B/jbxWIeejyCufI9x7/XzBiQ8gzDAofK48bXWmuDt2C6Kc5MzH/Loo5t1ZV7Ow+8fKs tLfwuJS6+LLF43cyWAk70VpSElPNRyfBjCnnN3sM= 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 In-Reply-To: <7e27-6088f880-ab-5a394d00@108443239> Date: Wed, 28 Apr 2021 22:19:01 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001791a9063c8-c7d5b566-f0d1-4606-a978-2e2d183284d7-000000@email.amazonses.com> References: <7e27-6088f880-ab-5a394d00@108443239> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.28-54.240.48.92 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 22:19:05 -0000 Hi Michal, > starting with the issue of the exact purpose of all these modules, I = may have misunderstood. It seemed to me they are meant to fully = configure an SSH server/client, NETCONF server/client, ... With the = limitation of leaving out some rare or too complex use-cases up to = augments. At least that is what I was trying to help you with, but these = criteria are subjective, of course. I=E2=80=99d say =E2=80=9Cfully configure, within reason.=E2=80=9D 1) Easy: TCP and TLS These are easy because they don't ever entail interacting with user = databases. 2) Moderate: SSH (password, publickey, hostbased, none) and HTTP (basic, = digest) These are moderate because there=E2=80=99s a potential for callouts = to remote user databases and, if so, then we don=E2=80=99t have the = model to define how to do those callout yet. However, a = simple/built-in user-database is straightforward to configure. [caveat: = some SSH servers (e.g., sshd) enable a multiplicity of these mechanisms = (e.g., first publickey, then password), which we don=E2=80=99t have an = answer for yet.] 3) Not Easy: SSH and HTTP, the other auth mechanisms. These are not easy because they seem to require callouts to = app-logic in order to be useful in a production environment. Assuming = static/canned responses are okay, it might be okay to enable these auth = mechanisms (via their features) for, e.g., unit-testing purposes. > Still, I think we are pretty close now, from my perspective. As was = discussed, the "keyboard-interactive" method is a completely generic one = where the user is presented with a set of challenges and must correctly = respond to them to pass the authentication. That should already work and = the issue I was trying to solve is a security one, when the expected = response is some sensitive information. Adding that, I think the = configuration would be able to (safely) express all configurations that = do not require any additional information (such as, I don't know, = retrieving the expected response from some remote server). Incidentally, = the expected response of the user password would also be supported. The problem with the current keyboard-interactive model is that each = =E2=80=9Cresponse=E2=80=9D is effectively a password, even if it=E2=80=99s= not a password, in that it is the magic answer that the client needs to = provide. =20 Thus, all the responses SHOULD be, e.g., hashed, so that the value that = needs to be provided isn=E2=80=99t in the clear. In this sense, we = could use the iana:crypt-hash type for the =E2=80=9Cresponse=E2=80=9D = node, pushing it to the administrator to configure the hashed values. That said, if we=E2=80=99re leaning towards static/canned = =E2=80=9Ckeyboard-interactive=E2=80=9D config being sold for, e.g., = unit-testing, it would be easier on the administrator to leave the = values in the clear. >>>> The ssh_config manage has: >>>>=20 >>>> PreferredAuthentications >>>> 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: >>>>=20 >>>> gssapi-with-mic,hostbased,publickey, >>>> keyboard-interactive,password >>>>=20 >>>> We could support this either by: >>>>=20 >>>> 1) wrap everything inside an =E2=80=9Cordered-by user=E2=80=9D list >>>>=20 >>>> 2) define a =E2=80=9CPreferredAuthentications=E2=80=9D like = variable, to provide an external ordering >>>>=20 >>>> Thoughts? >>>=20 >>> This is probably just a YANG modeling issue. I was already thinking = about 1) and it seems to me it would make for a nice configuration data, = but the YANG itself would be cluttered. Nevertheless, there may be a = clean solution I am missing so it is up to you. We have simply assigned = a priority to each authentication method, but I am not saying that is = ideal. >>=20 >> #1 seems better at first but, assuming the list is called = =E2=80=9Cauthentication-method=E2=80=9D, the immediate issue is what the = =E2=80=9Ckey=E2=80=9D should be. We=E2=80=99d have to introduce a = somewhat artificial =E2=80=9Cname=E2=80=9D node, which makes the = approach less appealing. >>=20 >> #2 seems easy enough: >>=20 >> leaf-list preferred-authentications { >> type enumeration { >> enum publickey { ... } >> enum password { ... } >> enum hostbased { ... } >> ... >> } >>=20 >> But new =E2=80=9Cenums=E2=80=9D cannot be augmented into an = =E2=80=9Cenumeration=E2=80=9D (in case that is ever desired). We could = use =E2=80=9Ctype string=E2=80=9D, but that's too open. Another option = would be to define a hierarchy of identities and then have a leaf-list = of identityrefs. This could work, but... >>=20 >> Now I=E2=80=99m thinking to leave the order unspecified, since it=E2=80= =99s a minor optimization (saving a round-trip), as the =E2=80=9Cnone=E2=80= =9D option can be used to get a =E2=80=9Cproductive methods=E2=80=9D = list from the server. >>=20 >> You said that you=E2=80=99d did this optimization before, but did it = really matter, to save one roundtrip, especially in the context of using = the keyboard-interactive method? >>=20 >> How about this for the the =E2=80=9Cclient-identity=E2=80=9D node=E2=80= =99s description? >>=20 >> "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." >=20 > Like I said, the best example of a problem we were solving with these = priorities was that when your SSH client has both "publickey" and = "password" authentications supported and working and you connect to an = SSH server that supports the "publickey" authentication, it is probably = the method you prefer. I may be missing something but how do you solve = this problem without some way of expressing these priorities explicitly? = I do not see how getting the supported methods from the server will help = you, it is strictly up to the client which of the methods it will select = next (first). I understand you=E2=80=99re trying to enable the client to know exactly = the right auth mechanism to use first. My last response was, = effectively, =E2=80=9Clet=E2=80=99s NOT solve that problem, because = it=E2=80=99s a minor optimization, saving just one round-trip." My question before was (and still is), since you did this optimization = before, did it really matter (to save that roundtrip), especially in the = context of using the (very slow) keyboard-interactive method? >>>>> 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. >>>>=20 >>>> Ack, and we shouldn't support a low-probability use-case. >>>>=20 >>>>=20 >>>>> 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. >>>>=20 >>>> I think what you are saying is: >>>>=20 >>>> 1) if a cert-to-name mapping is NOT found, then fallback to the = SSH-level username >>>>=20 >>>> 2) if a cert-to-name mapping IS found, then it SHOULD override the = SSH-level username. >>>=20 >>> If you decide to keep this mappings, I was suggesting a completely = generic solution when you could configure a specific username for the = cert-to-name mappings. >>>=20 >>> 1) If the user name is configured and >>> a) matches the SSH user name, you try to use the mapping and = override the SSH user name. >>> b) does not match the SSH user name, you ignore this mapping. >>=20 >>> 2) If the user name is not configured, you always try to use the = mapping. >>>=20 >>> But there is still the question of what to do if you find no = matching mapping. I suppose it could be a separate configuration leaf = deciding whether you want to fall back on the SSH user name or fail the = authentication altogether. >>=20 >> Added that mappings override the SSH-level username. >>=20 >> Added a separate configuration leaf for if a mapping is *required* >=20 > So you have decided to keep it? In any case, its functionality should = now be unambiguous. Yes, and yes. K. From nobody Wed Apr 28 15:19:18 2021 Return-Path: <010001791a90707c-15746988-caf5-4c8b-9199-5e389716a096-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 F40383A22CF for ; Wed, 28 Apr 2021 15:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 sqvmC0hzAGPp for ; Wed, 28 Apr 2021 15:19:05 -0700 (PDT) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937BD3A22AD for ; Wed, 28 Apr 2021 15:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619648344; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=mzgOFIp35TwwuDwpoCt4HvLtqKIcWoUL0Fi+pvfeDBw=; b=jRBNVmKHHJ7UDCBMQPJuayj/DKxGLYAum+EnECc61pt3vC7T/7cT0nEt4Kka3saJ D7NIkWDdHy+L/Bo5SKFNCmSp3mXHJ/gPO60tGLv/8tuuBmGy2efAN0/Rhiae9+ehVfQ /kcPhIlqVri+k/llo/MhMohgPawLWf2uvIqe6X5Q= 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 In-Reply-To: <20210428071116.33uc3m2vzo5gq6lf@anna.jacobs.jacobs-university.de> Date: Wed, 28 Apr 2021 22:19:04 +0000 Cc: =?utf-8?Q?Michal_Va=C5=A1ko?= , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001791a90707c-15746988-caf5-4c8b-9199-5e389716a096-000000@email.amazonses.com> References: <20210426172143.hhhebmeudv23dvkr@anna.jacobs.jacobs-university.de> <78fd-6087b600-7b-59cd2c00@214199368> <20210427073236.7s5fx2jzgs4hvhtc@anna.jacobs.jacobs-university.de> <0100017913b7c3d4-e03a2d29-4b0f-4820-bee9-56f532679207-000000@email.amazonses.com> <20210427155544.pd7bmt2hdztx2zui@anna.jacobs.jacobs-university.de> <0100017914bb076f-9fb97a64-b35a-474d-9222-9be5ec784aaf-000000@email.amazonses.com> <20210427210046.gtfcwwf5kefxfme5@anna.jacobs.jacobs-university.de> <01000179158224da-a7663485-0b99-42b8-b85d-804c9d17ec5f-000000@email.amazonses.com> <20210428071116.33uc3m2vzo5gq6lf@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.28-54.240.48.95 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 22:19:17 -0000 Hi Juergen, >>> a) Is the issue that there is no support for keyboard-interactive in >>> the SSH model? >>=20 >> There is now per this commit: = https://github.com/netconf-wg/ssh-client-server/commit/c434d249baeab8f850b= 25c0c4c518379accffcf0 = >>=20 >=20 > To me this makes little sense, you are not done by statically > configuring challenges and responses, this is from my view really > missing the point of keyboard interactive. I am sure you can write > a PAM module that does that but the value of keyboard is not this > kind of trivial configuration. >=20 > My point is that if we model keyboard-interactive, we have to get it > right, which is complex. Hence my suggestion is to not model it at = this > point in time. I tend to agree. While I also agree with Michal that the = =E2=80=9Ckeyboard-interactive=E2=80=9D model reflects RFC 4252, it = doesn=E2=80=99t seem practical in a production environment to have = canned prompts/responses beyond, e.g., developing unit tests. Take, for instance, the two examples in = https://tools.ietf.org/html/rfc4256#section-4. =20 The first example attempts to authenticate a crypto card, presumably by = getting it to perform a private-key operation over the =E2=80=9Cchallenge=E2= =80=9D. However, in a production environment, the challenge would have = to a random value each time (i.e., a nonce) as, otherwise it=E2=80=99s = susceptible to a replay attack. The second example reflects the case of an expiring password and the = need to generate a new one. First, passwords don=E2=80=99t expire *all* = the time, so having static config doesn=E2=80=99t make sense. Second, = there=E2=80=99s no way to predict the new password value, and hence the = =E2=80=9Cresponse=E2=80=9D could not be configured. Third, in order to = apply the password-change, app-logic (e.g., a callout) would be need = (e.g., to update a user database entry). Michal, you said that you used =E2=80=9Ckeyboard-interactive=E2=80=9D = before. Can you please provide a concrete example? Hopefully something = beyond just prompting for a password, which I contend SHOULD use the = =E2=80=9Cpassword=E2=80=9D auth method instead... > I also stumbled over >=20 > "A list of locally configured users (i.e., SSH clients)."; >=20 > For me, an SSH client and a locally configured user are very different > things. For me, the SSH client is the piece of code running on the > client side, the user is an account on the remote system. Yes, they are different things. >>> b) Is the issue that there is no support for non-local user = databases >>> for SSH and HTTP authentication? >>=20 >> If we think that is important, yes. The current =E2=80=9Csolution=E2=80= =9D for non-local user databases is 1) don=E2=80=99t enable = "client-auth-config-supported=E2=80=9D and 2) augment-in what is needed = for the application=E2=80=A6and maybe 3) only use TLS, where the = truststore/keystore + cert-to-name obviate the need for a user database. >>=20 >=20 > Well, you can configure SSH user authentication mechanism to reach out > to RADIUS or Kerberos or Diameter or ... RFC 7317 does support the > RADIUS backend option. Having to augment in new trees to support lets > say RADIUS is somewhat expensive. (I _assume_ you can call out to > RADIUS from the SSH password authentication method, i.e., this may not > require to have keyboard-interactive.) But perhaps also this can be > dealt with once there is more implementation experience. Exactly what is likely needed for a production environment. RFC 7317 = includes RADIUS-client config, which we could embrace and extend (to = support other mechanisms, e.g., LDAP, PAM, etc.), but this gets into the = =E2=80=9Cmore complicated than I want for now=E2=80=9D teritory. =20 My thinking, again, is to: 1) enable "static user auth=E2=80=9D to define a simple/built-in = user database with static/canned auth configs. 2) enable the =E2=80=9Cstatic user auth=E2=80=9D tree to be = disabled, so better (production-grade) mechanisms can be augmented-in. K. From nobody Wed Apr 28 22:41:10 2021 Return-Path: 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 7D29F3A30C6 for ; Wed, 28 Apr 2021 22:41:08 -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 Ss85L6_DVOTZ for ; Wed, 28 Apr 2021 22:41:03 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee: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 9065D3A30C5 for ; Wed, 28 Apr 2021 22:41:02 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 1065C6007D; Thu, 29 Apr 2021 07:40:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619674858; bh=MgAjAb40cN33JsXOBY8QFiliH/WwdnyR4itfR6BDXHI=; h=From:In-Reply-To:Date:Cc:To:Subject; b=PD9EpTW8n0in8fqDT7Ufc5monJhImiJYj9JMGq/XUf471Y5Gqm26cbmSHInIUn5dM kXJ1vk+R/Ht3+/AQXJ1cbUUCpu2mVK+bBN8CBt6ARjMMpNYA83/TMUi21pi2DO53i7 fgM/oVMqUscjzpzGNtvJ3pyT5p3yfZU1/1wmTs8I= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <010001791a9063c8-c7d5b566-f0d1-4606-a978-2e2d183284d7-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Thu, 29 Apr 2021 07:40:58 +0200 Cc: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <972-608a4700-29-1b90d060@24617716> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 05:41:09 -0000 Hi Kent, > > Still, I think we are pretty close now, from my perspective. As was= discussed, the "keyboard-interactive" method is a completely generic o= ne where the user is presented with a set of challenges and must correc= tly respond to them to pass the authentication. That should already wor= k and the issue I was trying to solve is a security one, when the expec= ted response is some sensitive information. Adding that, I think the co= nfiguration would be able to (safely) express all configurations that d= o not require any additional information (such as, I don't know, retrie= ving the expected response from some remote server). Incidentally, the = expected response of the user password would also be supported. > > The problem with the current keyboard-interactive model is that each = =E2=80=9Cresponse=E2=80=9D is effectively a password, even if it=E2=80=99= s not a password, in that it is the magic answer that the client needs = to provide. > > Thus, all the responses SHOULD be, e.g., hashed, so that the value th= at needs to be provided isn=E2=80=99t in the clear. In this sense, we = could use the iana:crypt-hash type for the =E2=80=9Cresponse=E2=80=9D n= ode, pushing it to the administrator to configure the hashed values. That is true and would make sense. > That said, if we=E2=80=99re leaning towards static/canned =E2=80=9Cke= yboard-interactive=E2=80=9D config being sold for, e.g., unit-testing, = it would be easier on the administrator to leave the values in the clea= r. I do not really see the point of having the configuration there just fo= r testing purposes. With all the feedback provided, it seems to me now = that all the configuration of "keyboard-interactive" should be scratche= d and leave it just as a presence container to allow augments. With a d= escription mentioning them and the possibility of using PAM or similar = authentication methods. > >>> This is probably just a YANG modeling issue. I was already thinki= ng about 1) and it seems to me it would make for a nice configuration d= ata, but the YANG itself would be cluttered. Nevertheless, there may be= a clean solution I am missing so it is up to you. We have simply assig= ned a priority to each authentication method, but I am not saying that = is ideal. > >> > >> #1 seems better at first but, assuming the list is called =E2=80=9C= authentication-method=E2=80=9D, the immediate issue is what the =E2=80=9C= key=E2=80=9D should be. We=E2=80=99d have to introduce a somewhat arti= ficial =E2=80=9Cname=E2=80=9D node, which makes the approach less appea= ling. > >> > >> #2 seems easy enough: > >> > >> leaf-list preferred-authentications { > >> type enumeration { > >> enum publickey { ... } > >> enum password { ... } > >> enum hostbased { ... } > >> ... > >> } > >> > >> But new =E2=80=9Cenums=E2=80=9D cannot be augmented into an =E2=80= =9Cenumeration=E2=80=9D (in case that is ever desired). We could use =E2= =80=9Ctype string=E2=80=9D, but that's too open. Another option would = be to define a hierarchy of identities and then have a leaf-list of ide= ntityrefs. This could work, but... > >> > >> Now I=E2=80=99m thinking to leave the order unspecified, since it=E2= =80=99s a minor optimization (saving a round-trip), as the =E2=80=9Cnon= e=E2=80=9D option can be used to get a =E2=80=9Cproductive methods=E2=80= =9D list from the server. > >> > >> You said that you=E2=80=99d did this optimization before, but did = it really matter, to save one roundtrip, especially in the context of u= sing the keyboard-interactive method? > >> > >> How about this for the the =E2=80=9Cclient-identity=E2=80=9D node=E2= =80=99s description? > >> > >> "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." > > > > Like I said, the best example of a problem we were solving with the= se priorities was that when your SSH client has both "publickey" and "p= assword" authentications supported and working and you connect to an SS= H server that supports the "publickey" authentication, it is probably t= he method you prefer. I may be missing something but how do you solve t= his problem without some way of expressing these priorities explicitly?= I do not see how getting the supported methods from the server will he= lp you, it is strictly up to the client which of the methods it will se= lect next (first). > > I understand you=E2=80=99re trying to enable the client to know exact= ly the right auth mechanism to use first. My last response was, effect= ively, =E2=80=9Clet=E2=80=99s NOT solve that problem, because it=E2=80=99= s a minor optimization, saving just one round-trip." > > My question before was (and still is), since you did this optimizatio= n before, did it really matter (to save that roundtrip), especially in = the context of using the (very slow) keyboard-interactive method? But how is it saving just one round-trip? If you are offered "password"= authentication but want to use "publickey" instead, let's say, you wil= l likely leave the input empty just so that it fails and you get to the= next method. But that causes a failed authentication attempt, if nothi= ng else, which I do not think is that harmless. Regards, Michal From nobody Thu Apr 29 06:48:13 2021 Return-Path: <010001791de3029b-730530a6-f4fb-4d57-9d39-a1551ab76260-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 B341C3A3F51 for ; Thu, 29 Apr 2021 06:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 yJtr7d1cCLzL for ; Thu, 29 Apr 2021 06:48:09 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538763A3F52 for ; Thu, 29 Apr 2021 06:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619704088; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=TXBZRRgmhCy+zDeEcNoGD6dII07SfmZO7Vnmo3Ek2OA=; b=Cg40iNlzY2jV8ZMbiu0+uaQuLvCuRqCvmvN7n/JwktWfqoDteeQco5d3uQWqZAvV uFaWwVwGwOrpEF7pX0RggkJtsuvAZZ3ZDIupiR3oghECC2aqURLezAuXqt5cU2o/+Ee ptZPQAgQa/aQawyDDFQdTI60+3Fug4XbdhL8889g= 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 In-Reply-To: <972-608a4700-29-1b90d060@24617716> Date: Thu, 29 Apr 2021 13:48:07 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001791de3029b-730530a6-f4fb-4d57-9d39-a1551ab76260-000000@email.amazonses.com> References: <972-608a4700-29-1b90d060@24617716> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.29-54.240.48.110 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 13:48:11 -0000 Hi Michal, > I do not really see the point of having the configuration there just = for testing purposes. With all the feedback provided, it seems to me now = that all the configuration of "keyboard-interactive" should be scratched = and leave it just as a presence container to allow augments. With a = description mentioning them and the possibility of using PAM or similar = authentication methods. Could provide how you used =E2=80=9Ckeyboard-interactive=E2=80=9D = before? Was config such as in the current model used, or was it = actually interacting with an PAM-like mechanism? =20 >> My question before was (and still is), since you did this = optimization before, did it really matter (to save that roundtrip), = especially in the context of using the (very slow) keyboard-interactive = method? >=20 > But how is it saving just one round-trip? If you are offered = "password" authentication but want to use "publickey" instead, let's = say, you will likely leave the input empty just so that it fails and you = get to the next method. But that causes a failed authentication attempt, = if nothing else, which I do not think is that harmless. I=E2=80=99m unsure if you understand the SSH protocol, so here goes: = the client starts off with an auth method. It can optimistically pick = one (e.g., if it only has one to choose, then it has nothing to lose by = picking it) or pick =E2=80=9Cnone=E2=80=9D. In either case, if the = server is unhappy with the method selected by the client (and it always = will be when =E2=80=9Cnone=E2=80=9D is selected), the server responds = with a list of =E2=80=9Cproductive=E2=80=9D methods the client should = try next. =20 The question is, how important is the ability to configure a =E2=80=9Cfirs= t=E2=80=9D method (assuming more than one has been configured)? My guess is that it=E2=80=99s not important as follows: 1) I assume the client is not resource-constrained (as, if it were, then = it would likely be using TLS instead of SSH). Thus, in the worst case, = where the client performs some expensive key operation, it=E2=80=99s not = a big deal because it has the resources to do it quickly. 2) Assuming the client sends an =E2=80=9Cexpensive method=E2=80=9D = first, and the server isn=E2=80=99t configured to support that method = first, it will not waste any CPU cycles doing an expensive key = operation; it will simple return a failure with a list of = =E2=80=9Cproductive=E2=80=9D methods. Thus the net-impact is some wasted CPU-cycles on the client and the = latency incurred by one unnecessary roundtrip. Assuming the client is = not resource-constrained, the only significant variable is the network = and, in a very high-latency network, it could be important. Thoughts? K. From nobody Thu Apr 29 07:56:48 2021 Return-Path: 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 A22733A0BB3 for ; Thu, 29 Apr 2021 07:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 MI0tHRUkxBfe for ; Thu, 29 Apr 2021 07:56:42 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee: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 CB9193A0BB1 for ; Thu, 29 Apr 2021 07:56:41 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id 00940600B2; Thu, 29 Apr 2021 16:56:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619708196; bh=27Cu+n8pttbF+HiQN73L7aGdNiA0V51RB83JWV9F1rA=; h=From:In-Reply-To:Date:Cc:To:Subject; b=xuC/xuPnq9NzZS5AazTiNcslX4AiGZ3eol3p+nGeQIbSsfbKxi/RrIC3IuD/5SYCt j1IVtIXzTF1U4nLq/xkkazh7dcadERzBlQkxUA0mz2BO7JYemV++1sYQRYQcMMzCxw m+RRzy3c/qIqR6XKkTZMvI6G7AGgkYGXcaoyvWf8= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <010001791de3029b-730530a6-f4fb-4d57-9d39-a1551ab76260-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Thu, 29 Apr 2021 16:56:35 +0200 Cc: =?utf-8?q?netconf=40ietf.org?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <62ed-608ac900-53-32820540@104833101> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 14:56:47 -0000 Hi Kent, > > I do not really see the point of having the configuration there jus= t for testing purposes. With all the feedback provided, it seems to me = now that all the configuration of "keyboard-interactive" should be scra= tched and leave it just as a presence container to allow augments. With= a description mentioning them and the possibility of using PAM or simi= lar authentication methods. > > Could provide how you used =E2=80=9Ckeyboard-interactive=E2=80=9D bef= ore? Was config such as in the current model used, or was it actually = interacting with an PAM-like mechanism? Currently, we do not use PAM but directly ask for the user password for= the "keyboard-interactive" method. But it seems to me this may be wron= g and definitely not the intended use so I will probably rewrite it onc= e these modules are published and we are migrating to them. > >> My question before was (and still is), since you did this optimiza= tion before, did it really matter (to save that roundtrip), especially = in the context of using the (very slow) keyboard-interactive method? > > > > But how is it saving just one round-trip? If you are offered "passw= ord" authentication but want to use "publickey" instead, let's say, you= will likely leave the input empty just so that it fails and you get to= the next method. But that causes a failed authentication attempt, if n= othing else, which I do not think is that harmless. > > I=E2=80=99m unsure if you understand the SSH protocol, so here goes: = the client starts off with an auth method. It can optimistically pick= one (e.g., if it only has one to choose, then it has nothing to lose b= y picking it) or pick =E2=80=9Cnone=E2=80=9D. In either case, if the = server is unhappy with the method selected by the client (and it always= will be when =E2=80=9Cnone=E2=80=9D is selected), the server responds = with a list of =E2=80=9Cproductive=E2=80=9D methods the client should t= ry next. > > The question is, how important is the ability to configure a =E2=80=9C= first=E2=80=9D method (assuming more than one has been configured)? > > My guess is that it=E2=80=99s not important as follows: > > 1) I assume the client is not resource-constrained (as, if it were, t= hen it would likely be using TLS instead of SSH). Thus, in the worst c= ase, where the client performs some expensive key operation, it=E2=80=99= s not a big deal because it has the resources to do it quickly. > > 2) Assuming the client sends an =E2=80=9Cexpensive method=E2=80=9D fi= rst, and the server isn=E2=80=99t configured to support that method fir= st, it will not waste any CPU cycles doing an expensive key operation; = it will simple return a failure with a list of =E2=80=9Cproductive=E2=80= =9D methods. > > Thus the net-impact is some wasted CPU-cycles on the client and the l= atency incurred by one unnecessary roundtrip. Assuming the client is n= ot resource-constrained, the only significant variable is the network a= nd, in a very high-latency network, it could be important. Thoughts? I am not sure what the problem is but it seems we are still not underst= anding each other. My specific example is as follows. The client uses "= none" method first to get the list of supported methods, always. Then, = based on the returned methods, it gets the set of supported methods on = both the server and the client. The problem is, what should be the orde= r of trying to authenticate using these methods? Like I said before, if= a more complex method is selected instead of a simpler one, it may res= ult in additional failed authentication attempt (and client disconnect = if none are allowed), minor user annoyance, and even wasted server CPU = time, yes. I consider the first problem serious enough that would like = the module to support configuration that could prevent it. Regards, Michal From nobody Thu Apr 29 08:09:40 2021 Return-Path: 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 D4AC13A287F for ; Thu, 29 Apr 2021 08:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 Jz06WlxmGdlP for ; Thu, 29 Apr 2021 08:09:33 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70051.outbound.protection.outlook.com [40.107.7.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4B03A0E0F for ; Thu, 29 Apr 2021 08:09:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KvUqBhOy54zf7sjARSkB2YziZzTHYIdyH6VmutDADKiNjrRoAj2U1XlIb5j1WzGcXlQr4yld8q91lXr3I6Brl/9fuBgzdqTwUJlXGx26h139Z5vYZGk8/q7YB7kqKWYy23eHG48K6xP3nadk8hUxQIXvzIgbJo/II1hWcp459C6FNazRAxrDLBep2lS0vAcUq+60PE6ZtYhyKpiu2OWLtgtl1oQ8Imy8GF4E5NCkLRl2LcqBvZvpyt0zUVfoOcIArz7qvgQAcKnQB5f57aItpIu6JZLu3a7o+3voTOgHKkyeotb2LLib2C1sP56Ct9ijmFnPxhQDhBPLamCTygbq8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ec1kLVV4wSu1OKPePBDEHn4HtAtbI/ihpunNwm4XUQ=; b=L7q6+/5sMXNPDPdwtTiIqVSbdy7Xv3xtWo8TvsjQhmoihu4dPQdlnEls6hrQbutShNOlrcVaQ5KqsGsVLQlPMln6ovhrH/SzgSUjIslJtq7KVEQbtXOUX+d9sKy8XyFfvtrxFwaprcGik95wTdO3fDjYDOwroL93CSXYdh3tgbkk0YUrA1kF+jsC1d1roHaoZe3BpzjmVXlCfcAQUSwcU7qJo1b49uN8pTM3zkm3DXuVU5DI6EHATraZFOtM0CzBhVhcIHWEt9285Ib/U6xsNBZDccVsP95XNJd3abwYqYc+x2OX0XYgyxwFJv6CNvbFbKXLSaZt82XSC7uSOJwS5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ec1kLVV4wSu1OKPePBDEHn4HtAtbI/ihpunNwm4XUQ=; b=HjWEI75x6md1LTQ/dlvWUJO9/pqEmIj2sClXUgCN7nPEXheIGYIDywXu7V62C7+CfQ9a9vElq1SGVr2P8NJMjRr1y6Z4ahjVHTJ8tdOO+lC1PYSEF8SVr1dJuMaIH3sVjPBQ497x1AXZpMJGwB0XRuDpU7ntkzga52jlRVLhIpk= Authentication-Results: cesnet.cz; dkim=none (message not signed) header.d=none;cesnet.cz; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1684.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3e9::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.22; Thu, 29 Apr 2021 15:09:29 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4087.026; Thu, 29 Apr 2021 15:09:29 +0000 Date: Thu, 29 Apr 2021 17:09:28 +0200 From: Juergen Schoenwaelder To: Michal =?utf-8?B?VmHFoWtv?= Cc: Kent Watsen , "netconf@ietf.org" Message-ID: <20210429150928.3rwjhc3llseofssa@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michal =?utf-8?B?VmHFoWtv?= , Kent Watsen , "netconf@ietf.org" References: <010001791de3029b-730530a6-f4fb-4d57-9d39-a1551ab76260-000000@email.amazonses.com> <62ed-608ac900-53-32820540@104833101> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <62ed-608ac900-53-32820540@104833101> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: FRYP281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::20) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by FRYP281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.10 via Frontend Transport; Thu, 29 Apr 2021 15:09:29 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2ffb36f8-19e4-46e5-56da-08d90b20c966 X-MS-TrafficTypeDiagnostic: AM9P190MB1684: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Nta5UkI53PBVcCq0+gz8TwcVPjH2zwMtDBk0U2603g3WkVDb3kpY94a11JdLxs1nc+eNa/RlNhloCcb1cCG80Iukx6HAbID0jJZq9LYp5QHd0udXHwqaejwphUg1N7HuLQTQct2wSM8ULX5Oc1DqInc8jz7KLxFQzWA1Qs5/H8ExilD6tODiuQ7/cgJVkuxFofKEbwifl8TXuBhY+8W7rMX2Gim8pGp7MmFCqdrXCSB3tpNVIW/UA3SNj9VG5v5krukcFIEEIUukW3fPFS6Jy4YaVjPHvMVpTab9R8rzBr+OBMGtL8KVKPWa/LiV7/xGn16Nr5bjpZPlBm5jWRPL6z/a32JdybEr+5fd4ZBzfm/6YICh4ZXf9QZ/8Ig5uRULTIPTrzHQZMV0yaMXTHnTtplvgtcaqa5rDGSTTvYYI7UG3EE1ByLWmQcgcNkdSXsfOldWYOGTj9vEcb3ijGWJVQH2WLEPMPJd9yvK8VaDwXl1sG65bK6YvrsZjDWnZO96rV49NaPQnl/s5kj2rm3IHN8pIypz3YB3GVeXihNwHp5/qqdOT0xI23pGgM8e4SRIA4R2N1heNb78jUv1UmMeSQK6huA11aKQTsKBNYgXsK8qv3pcoawm+hZl6MVjXMzRUDwb7G8AZzDkUKaT0aqtdgfzI299iqsl+mMUmRN5SlfVEiODp8cQlndj9TtITvb4B5GXM/EMo77uX9vEFfXPWfzG3RgtWlgjptPPWU3qq4U= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39840400004)(136003)(346002)(376002)(396003)(366004)(478600001)(83380400001)(2906002)(3450700001)(54906003)(16526019)(66946007)(956004)(786003)(86362001)(316002)(6916009)(1076003)(5660300002)(8676002)(26005)(186003)(6496006)(6486002)(66574015)(38350700002)(66476007)(8936002)(38100700002)(4326008)(66556008)(52116002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?QlpIYjUwendRbkc0b1R4UllWdFRld3hQNjE0UE45MUY3Zmc5TG5YZ1JlbGw4?= =?utf-8?B?aVMwd1k5VXl5dHdyT3VLS0lZeGpNV3dzRm1LTWw1akVFcCttbEhtUTBCc3Ja?= =?utf-8?B?T3NHODZxMlBaYS9pZ1lZRjJBYlFkQ2tTbzlQQmFPQ1c5WlFsT3RFTXd3U1gw?= =?utf-8?B?ZjZjWUl4cEdZQnFLUUNESnYwZXBRdVdKSUFLbW53UzgyM2hraFdYdkV6QmZU?= =?utf-8?B?VzIyVVNPU0t2N3VJT2d1dUczM01GbXoxSnV3VmdIOWZ4ZEUwNFl3Njdkb1ZO?= =?utf-8?B?TmtnSzhKQ21hNXEwNi9kRjVTNXk4aFJWQzMvMHQ5SVFWbXNMZ0JDYjBYL3Rl?= =?utf-8?B?RXE3d0dUK1J3WE5UZFpBMDA3ZXRQOUU2MGhMSmxKWmprdjgxS3A1a01SclFh?= =?utf-8?B?ci81TFU5Nkt1Zmh0MDFod1dvZG5ra0JLVEJZSExOMkpTYVBLOENqS0JkSG9N?= =?utf-8?B?ejVlSllPeGZuNUhUa2pGVitQZy9PR2lBUEZ0NCtxcWY2ZWRITUNXY0JUVnVh?= =?utf-8?B?ZlVPNnRlWTJOelhiM0lCR2pyc05CY2NwYWJJK2p3akFRbXQxY0pTYzFvTE9s?= =?utf-8?B?S3ZGN3llUnJ3aUhsYW5UNlpxZENZTW5oNk9oUWhaT2V2UGIwV0pObFlBd0dD?= =?utf-8?B?Yi9PWHhRbWd5Nm1kTHlScVNqK29kaFlXWjBFQlRXRXU2UXUwZzlUUW0xSWMx?= =?utf-8?B?R1hEaEhsdFl5MWY4RVc1Q0JpVWlmY0Z0L0E5V3lnbVllUExZZ2JBQ216Ymlr?= =?utf-8?B?R3k3aFM0dXlLNC9tbk15QjQ4dURwKzNoVmZ5UW5WeHBZa3hkZ2ZuOHdIV3Z3?= =?utf-8?B?TDV1UE0yRDY2M0JLS0NPWURkR0loMDgrcU43azcwZ2JGbjFyVVZsUG5BdjN1?= =?utf-8?B?MGNremozSTZ4WjBqVWZLa0MyS3ZBY0lxOUJYMWtBS2ppeWxFcXR4a0lRdnZn?= =?utf-8?B?QXpiZXMvMXNBUEx6QnYweXBNeGFXdDNwbkd0VU5OYVE4SEV5RmhpQTZ1TTNB?= =?utf-8?B?M3M1N01yV2NhWng4VXh5YjlsZkJJcUFlU1ltSW1kajVldmF2STJ4SHpWL3lw?= =?utf-8?B?UkVnd0pYU29WU2ZNNElXMjNPVlp6bGpBbTZzNG1pUXRYZVdtcjZ1a2dwdnJo?= =?utf-8?B?SXovSHJDVkhoNXROTzBWT1VtUUZ4ZjVSdS9yLytJUkZvKzdNenNTRFFtWVFm?= =?utf-8?B?QUd5a1pqOHJvTWZnTllTQUpGa0w4dktyb1VZOVpXWHp3cHAveHVPM0JLMlYv?= =?utf-8?B?RStUejFET01uMElaOHhTaGFJNXg5WSt3aHE5ZG9mSjVpOTVnZ2VucDRLdURa?= =?utf-8?B?NW93bFF4WEh3Vzk0WWE3d1lOK0kvbGoxcnB3RnVJM1EvR2RKNmFHWVhrVGJn?= =?utf-8?B?ZUFvZ01QMmxaYzg5bnVKR0FwVDJBTEZSU0JjMFh0MDVzRkRRYTNncXNHcUhm?= =?utf-8?B?bGFyWWE4Y09BOEVXMWlpN1pzcm1aVzRBbWNERjhqYTZtR2tnZGNjYmZTTGpD?= =?utf-8?B?RWI0RVRKbmQ5aVl2UjFoQmFsTzZBWTV6M1Q3VmlIOW9CTEQ1eFhLTGdsY2R6?= =?utf-8?B?eUJyU1I5b21zUnV6Vm9TM0NJamhnK3FlUVJOSExTTG54TjNUOUFCRi9lb2M0?= =?utf-8?B?V3pLNWFESGZRSUVXL3k5d0dYQSszYUpnb3BtQUUvOC9TOTlobm1EaG92c2R0?= =?utf-8?B?dHdPL24xdjVCSmhtbDBFdzZqNnNEUU04Q0hUeUgwRlJ5bitlRnFrbUlzUjRU?= =?utf-8?Q?B4qNgWinRmetYxS4adgLWUy+x/Qxl7NYtXxjDIu?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 2ffb36f8-19e4-46e5-56da-08d90b20c966 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2021 15:09:29.6686 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: NnKb9XGY2f9zHhs1EN7aSovwmxaJx7YkrKhOybhA0VyEWA1DKdjtJKLoicneWRul5kI/AMH82lJbSoyMbpW6PVbbBMOJprKZvnwaUWIC4Jo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1684 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 15:09:39 -0000 On Thu, Apr 29, 2021 at 04:56:35PM +0200, Michal Vaško wrote: > > The question is, how important is the ability to configure a “first” method (assuming more than one has been configured)? > > > > My guess is that it’s not important as follows: > > > > 1) I assume the client is not resource-constrained (as, if it were, then it would likely be using TLS instead of SSH). Thus, in the worst case, where the client performs some expensive key operation, it’s not a big deal because it has the resources to do it quickly. > > > > 2) Assuming the client sends an “expensive method” first, and the server isn’t configured to support that method first, it will not waste any CPU cycles doing an expensive key operation; it will simple return a failure with a list of “productive” methods. > > > > Thus the net-impact is some wasted CPU-cycles on the client and the latency incurred by one unnecessary roundtrip. Assuming the client is not resource-constrained, the only significant variable is the network and, in a very high-latency network, it could be important. Thoughts? > > I am not sure what the problem is but it seems we are still not understanding each other. My specific example is as follows. The client uses "none" method first to get the list of supported methods, always. Then, based on the returned methods, it gets the set of supported methods on both the server and the client. The problem is, what should be the order of trying to authenticate using these methods? Like I said before, if a more complex method is selected instead of a simpler one, it may result in additional failed authentication attempt (and client disconnect if none are allowed), minor user annoyance, and even wasted server CPU time, yes. I consider the first problem serious enough that would like the module to support configuration that could prevent it. > RFC 4252 says: The server drives the authentication by telling the client which authentication methods can be used to continue the exchange at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user, when multiple methods are offered by the server. So the client does have to choose. Looking into the ssh(1) man page of OpenSSH, I find this: The methods available for authentication are: GSSAPI-based authentica- tion, host-based authentication, public key authentication, challenge-re- sponse authentication, and password authentication. Authentication meth- ods are tried in the order specified above, though PreferredAuthentications can be used to change the default order. 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. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 29 08:14:15 2021 Return-Path: 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 876FC3A289D for ; Thu, 29 Apr 2021 08:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 wsSrWxAN_Ofd for ; Thu, 29 Apr 2021 08:14:07 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2054.outbound.protection.outlook.com [40.107.21.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4DE3A2892 for ; Thu, 29 Apr 2021 08:14:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CmNn+3aRZciHrVAzo5ofcHTacJbD/+c5fUCDcD/Lu1+OKgkX69WhwOv93hpb7Y4dnA+YHcxMlRadsv4Lnt7HALMHz0cN6BjWGNeAhkTIiBv6FRp5n1iI1ERuG4UkQOXeZnhhLYyaj3TPPcbnM0sTpuw0nFojlITlzeSuH8uC3qxK0bNuF5TofNiGhYUNZ+WxiS+R7P31tivH2svh24Omxd1lJPtf8aKFAjkbdpWwrSBXZ/TSORfjEmmonrtP/uScjrvUETioaDSqzxMzS3otwhiTWtPYAjUne/e91zdl91+xifJWWoTvkKe3t9LkeRK/xu99xQX6RXPNQC0r8xwX3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NBxkcp7YXrJevToN3z8ht8ZrVaZCC6adZW59oGcR5Ok=; b=ft+4kBnBj2NCSr6rQeF0/E7Rlh1Dn3Xp7tRpiRzpLdcjygjaMF2BNAA4OmxfCYuFwnoqWIyUWnmMiGOMfi1oQhv1qP1UCoQuJjX1swIGbCE0wzJv9QOCUmdMQUT5+eG9Sn8lkq0uCAFICt37gK1Yj/p/CQ+VrUKgcORCnRkNKAS+W661TPSjRhmK8pnlAm/K42X57aOBZ0uZ6YCtCe5mwF+7oI+oTv3fe/37UQC1ir4Hvbcs8Dj4Fcu0DGK+SXo5w1g+wNgfBhj0fcFS4lTwkdmIDCvzLGyMKAiObIhqR1ZN08gUSQdpA+iQqBzZDsTewl1T+i/8KCI14CX8LQt9aQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NBxkcp7YXrJevToN3z8ht8ZrVaZCC6adZW59oGcR5Ok=; b=W/Vme83/Co3KS22Dj9vSPFqTvccFeZ5yztu9x+Zqn/R+NUA1rIqj30McGSdBwZXTx3TAP4f+oLUWR9FdlUVG928xkXxynNtD13+oxK24qCJhjc7j24yTiK9wh32757fJ7dXDfR3SgSzl0chY99+Trq16dNCoBqrW5JB457Lczos= Authentication-Results: cesnet.cz; dkim=none (message not signed) header.d=none;cesnet.cz; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0675.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:19f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Thu, 29 Apr 2021 15:14:04 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4087.026; Thu, 29 Apr 2021 15:14:04 +0000 Date: Thu, 29 Apr 2021 17:14:04 +0200 From: Juergen Schoenwaelder To: Michal =?utf-8?B?VmHFoWtv?= , Kent Watsen , "netconf@ietf.org" Message-ID: <20210429151404.uwmfdlhzwsroaxe7@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michal =?utf-8?B?VmHFoWtv?= , Kent Watsen , "netconf@ietf.org" References: <010001791de3029b-730530a6-f4fb-4d57-9d39-a1551ab76260-000000@email.amazonses.com> <62ed-608ac900-53-32820540@104833101> <20210429150928.3rwjhc3llseofssa@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210429150928.3rwjhc3llseofssa@anna.jacobs.jacobs-university.de> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: AM3PR04CA0132.eurprd04.prod.outlook.com (2603:10a6:207::16) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM3PR04CA0132.eurprd04.prod.outlook.com (2603:10a6:207::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.29 via Frontend Transport; Thu, 29 Apr 2021 15:14:04 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 61d47587-0e4c-4409-2e94-08d90b216d55 X-MS-TrafficTypeDiagnostic: AM0P190MB0675: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 42K4y+BswKfV2b5dt0kZNri5j56qquWAjxdvVyjU0dw1aK6V87PbnkcLTGCtzZPTzhl9XKg/gzjAThwm74gMqiSmZs2okfMtpa2PNZiWZ+dO5OWNzuaOfJ9IsdPfiS1WzOBz+MQJOZNfgxGXLwwWuyVDv/H+gir/HPKOTYV6/8EjOFSS+n4iMNCildpUDpJQncrS+vSCUofbDO9Q7W/dsLjR1mMq5ayvPZUdFDhQV8SMY4uTgRZhjZ0XNT3tQWqvadPV/qD60bxquR11+U2aF8BmUm7cdrOktUmXELanmZhR9+ZuILUOqRQHS3utmBUxfSc8u7jG2WzQiPH36GK63J0tws9UyqSrlTizaUcVdLUgDgQhmPnDjLcPVtAT35A2kk8rd46Ler5ORm7Y+/LrV8utCDbs15J/RQrOA838G7hXGj0X1M9W5jAPUGvFe2HGYOQfCzmZ83Idnz863fzn56oXod3nzlq4/rOhbk/DEt4JmD+hslNDZs4HJA7PbZ4RVpKFkDtME/22p81A9xst1K2Z9URT103fveIXkK8vZD09VC8UvM97nXdJS7lGuZ1PQmJ7DpqKHNVCk/sP+NMhNdII5g6UPIySVa2hsYgLiXp/Tpfj4OzmZTaX3s9SUvZ9AhwewCoz7ZjmkcNbvn6n06vfiYuOnuImLXyZt39l/5/+F/UGUUU+ZPlwLIed2c9R3CPptETLUsgo66G5JMfjdWJUEOlPUjQrM8Kd4W5n2GkAVWqnqszIYyks+RQWtu+k X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(396003)(39840400004)(136003)(83380400001)(186003)(956004)(4744005)(1076003)(5660300002)(110136005)(16526019)(26005)(86362001)(3450700001)(8936002)(6486002)(8676002)(52116002)(66946007)(66476007)(6496006)(786003)(316002)(2906002)(38350700002)(38100700002)(478600001)(66556008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?IyZFRHd7CiEKxt6c+6BLeXE1LulyW0HemN+RXnar6pp9V8MQ+QjsNUlnfHW5?= =?us-ascii?Q?k4jJm50V40CWQWNQW3UdcU791CV2kpD4YogWL5XR78XJ21mvUSHLhRnkxCm4?= =?us-ascii?Q?q97pjaW6JVeeR2P31IOzqOYAcdntVq1B2SyntT70S6UNj1ugqe1tOTWx6nZe?= =?us-ascii?Q?Y2ZzlBQKcJrvfAOgtIrs+NpWo0QsfO5vntYyDz9VxhUsDZ09b9NvJCtNxMrj?= =?us-ascii?Q?ZBB3Bq5Z7Myj7YzL0Q90JxdUib9NvXhYnbe2dxn3M7zKnyQRuWfTjYUUL4K3?= =?us-ascii?Q?1uxb8OwxX4K9NsIQ23U8OV5ZRp/NSv2psFH7wPxpq86Gr8ZngjiHpfN1/wyW?= =?us-ascii?Q?HYNfsvtAbgKH6E6yxfQ+gdClqKnCATCjWgJbkp9wqKM6Kd085Acwf4hChKVS?= =?us-ascii?Q?rtq+Wu54J9oFFmEFPnYevFBTBHmoaKsCZK0DdvL5IxdgnYMmL4Ejc0K6ZhHv?= =?us-ascii?Q?3fupEOi5M5EZCLzofjbpCEm03DX59jIFeG/2bOika3kI9GFrZ2EIn+1rPmGg?= =?us-ascii?Q?s+di2SNmTHdEd7V2q2kppeats/2h3QW3UsRz5zQLdCDLkjcWHq+7ucehZGmf?= =?us-ascii?Q?0tN60/U3zH0zBFtPazrZtfKwN/FR+7gabZ9UwHHY4yimTnf178RL/eW5lvJn?= =?us-ascii?Q?DZi//iAgRsjXXOxHJgbhlMJEvs84OKASQVTbjlQOGqeSixWsihR473dv1cTY?= =?us-ascii?Q?x5Kzbdgl4fedEnmJ10JxEP4ho/tGJLGM2ZQ8h9yLwJG/XH6QOQ3j+Q3cRtMz?= =?us-ascii?Q?f76i7eG5KOFzW/ZTYGSh2QhQ9WwKHi7YnONRRJalZ5oZNlbESXM5mhEOb/Y7?= =?us-ascii?Q?r6gNF0k643iRB99a9jn2QW80ZOdC2CHYdWy2pbo7XsnFi4K6uWHHIICxG8I7?= =?us-ascii?Q?oGV25NZSPxGNBIg1vU9nWFWgcs3E/FnYq7OijObJkedRbfiIREGLoJBoN3eH?= =?us-ascii?Q?Zd5d/Z29xycSldP8BG6ikVwU0ORdZOtDJfvW3QY6Ct3XbpsSlHkapeVLUer/?= =?us-ascii?Q?cjp+gLAMkLVITvL+Xkt7/8WnDA5XtY7t9+iML3PmlfMLLRCop8Vkl6DvPhnI?= =?us-ascii?Q?p38SjO9RiYekA7TqDRWGXaC1xwqtE3yixt856RVk2xX5dOsAvc4f52RleYNY?= =?us-ascii?Q?nq/w3sqP8LaWxcryEdYvh2p1Ld5SMaJHPjXEG/lNM9nzid8o8ZBqCOvliFX6?= =?us-ascii?Q?0n7SAdicHVMwOkREpBW1h99z+DWcMTjRIOHrlobK/9DCMA9emhFGWx4T8Sq8?= =?us-ascii?Q?f40Fh8LOqVG+Xw08wAL5dtkbZHmdLVkP90ptIxjIfWpZp2tnEUq/tQqJ+Us5?= =?us-ascii?Q?H+A2pMQBjtsgeaIZFZ3QkanL?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 61d47587-0e4c-4409-2e94-08d90b216d55 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2021 15:14:04.6567 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: eZP6QYAhDtvpuReWMhvYAGINR4S+wXs/HD8yX76bHe0YVkMT2uXSX8b+B7CwKYxpB/gHmsbKJejtZ5vh7PoipoxEoz+r0AJFf7FP1DUHnLU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0675 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 15:14:14 -0000 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. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 29 11:05:23 2021 Return-Path: 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 16A153A112D for ; Thu, 29 Apr 2021 11:05:22 -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 kNAva5WgTz2b for ; Thu, 29 Apr 2021 11:05:17 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee: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 00D763A1132 for ; Thu, 29 Apr 2021 11:05:16 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id F0ACA600B4; Thu, 29 Apr 2021 20:05:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1619719508; bh=AvIUZExbV9kP22hZQ/6GGeLc1GcBm/5lIF8Ra9WxrAo=; h=From:In-Reply-To:Date:Cc:To:Subject; b=w0+CJEEI4Q2ZM9NQNKGQAPYp0PwSgdmNQwFti1TWaPUT3NY8GPPGwueGie2vxdyU8 d/XieB5gYrkJl7cfxyu4Job2BJi5mimp49HZIlk2KnKZffZLon21zf85r86KjhqxHz nC9rvFCQdU4VUV3R0ZJJc9ZmkFpqlsoIxAM6hb3k= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: <20210429151404.uwmfdlhzwsroaxe7@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset="utf-8" X-Forward: 84.42.188.124 Date: Thu, 29 Apr 2021 20:05:08 +0200 Cc: "Kent Watsen" , =?utf-8?q?netconf=40ietf.org?= To: "Juergen Schoenwaelder" MIME-Version: 1.0 Message-ID: <971-608af580-15-2e293dc0@34342692> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?Latest_ietf-netconf-server_draft_and_related?= =?utf-8?q?_modules?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 18:05:22 -0000 On Thursday, April 29, 2021 17:14 CEST, Juergen Schoenwaelder wrote: > On Thu, Apr 29, 2021 at 05:09:28PM +0200, Juergen Schoenwaelder wrote= : > > And ssh=5Fconfig(5) says: > > > > Specifies the order in which the client should try authenticatio= n > > 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 sho= uld cover the majority of use-cases. Michal From nobody Thu Apr 29 11:35:51 2021 Return-Path: <010001791eea5b0b-5d7df7f0-78ce-4382-b27f-3c60ab42e1a2-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 20F783A1260 for ; Thu, 29 Apr 2021 11:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 gCwHhRaFuoR6 for ; Thu, 29 Apr 2021 11:35:48 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC22C3A125E for ; Thu, 29 Apr 2021 11:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619721346; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=iuaw99xGTvVsV3NYeDgpAcqT4PcbSc3JUFw7pKxtAd0=; b=kqPa9lunDm3f/JUiuqGorge63uDQRuJTcMMYS/6XI+XchV38IdnyVZAcWpfwwTGb ol3mQMUxkCMaZNl8aoIBg/Br/dn3GTcHj/q+bsL4O3qnWH6XidD3hwjCuWxOpp57Tvv FT3wPjAH3nXMf9VyfW8uBCzBP1TKcvrvGY1K+zCA= 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 In-Reply-To: <20210429150928.3rwjhc3llseofssa@anna.jacobs.jacobs-university.de> Date: Thu, 29 Apr 2021 18:35:45 +0000 Cc: =?utf-8?Q?Michal_Va=C5=A1ko?= , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001791eea5b0b-5d7df7f0-78ce-4382-b27f-3c60ab42e1a2-000000@email.amazonses.com> References: <010001791de3029b-730530a6-f4fb-4d57-9d39-a1551ab76260-000000@email.amazonses.com> <62ed-608ac900-53-32820540@104833101> <20210429150928.3rwjhc3llseofssa@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.29-54.240.48.94 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 18:35:49 -0000 > RFC 4252 says: >=20 > The server drives the authentication by telling the client which > authentication methods can be used to continue the exchange at any > given time. The client has the freedom to try the methods listed by > the server in any order. This gives the server complete control = over > the authentication process if desired, but also gives enough > flexibility for the client to use the methods it supports or that = are > most convenient for the user, when multiple methods are offered by > the server. And the RFC goes on to say: The 'authentications that can continue' is a comma-separated name- list of authentication 'method name' values that may productively continue the authentication dialog. It is RECOMMENDED that servers only include those 'method name' values in the name-list that are actually useful. However, it is not illegal to include 'method name' values that cannot be used to authenticate the user. All of the methods returned SHOULD be productive for the client to = choose next. It doesn=E2=80=99t matter (from a protocol perspective) = which method is selected, assuming more than one was returned. Kent From nobody Thu Apr 29 11:36:23 2021 Return-Path: <010001791eead163-ac714f94-ac4f-455a-adcf-20577ce13dc4-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 ECB8D3A1262 for ; Thu, 29 Apr 2021 11:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 oz8Zqh_496sf for ; Thu, 29 Apr 2021 11:36:17 -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 9E8933A1267 for ; Thu, 29 Apr 2021 11:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1619721376; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=P2fDjVtOBUQZ65dMMJEPjDe/3lVwKbAGnqtFXA8U8y4=; b=MYQryoQR/KniIF2nWs1t0ZvJeP3y2pSL6kAt77VZHETM6rsk/UbMbDVOwKa2CSki 3UI6EplaUDPRwMs4cRT1484+pi5l0x1leBjXQISMOh6evZT7qYx87pi4jr5/V3IqJiG YrVpIqmzhWqS7YR/GK0mE1nAgIsQ8vKMCTdwRIwA= From: Kent Watsen Message-ID: <010001791eead163-ac714f94-ac4f-455a-adcf-20577ce13dc4-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9C8EC8D4-1AB1-4F4E-93D5-0F300E710E3D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 29 Apr 2021 18:36:16 +0000 In-Reply-To: <971-608af580-15-2e293dc0@34342692> Cc: Juergen Schoenwaelder , "netconf@ietf.org" To: =?utf-8?Q?Michal_Va=C5=A1ko?= References: <971-608af580-15-2e293dc0@34342692> X-Mailer: Apple Mail (2.3654.60.0.2.21) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.04.29-54.240.8.83 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 18:36:22 -0000 --Apple-Mail=_9C8EC8D4-1AB1-4F4E-93D5-0F300E710E3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 29, 2021, at 2:05 PM, Michal Va=C5=A1ko = wrote: >=20 > On Thursday, April 29, 2021 17:14 CEST, Juergen Schoenwaelder = wrote: >=20 >> On Thu, Apr 29, 2021 at 05:09:28PM +0200, Juergen Schoenwaelder = wrote: >>> And ssh_config(5) says: >>>=20 >>> 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: >>>=20 >>> gssapi-with-mic,hostbased,publickey, >>> keyboard-interactive,password >>>=20 >>> I have no idea how popular it is to change the default order, which = is >>> likely what most people expect. >>=20 >> 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. >=20 > Fair enough, that sounds reasonable and I suppose the default order = should cover the majority of use-cases. >=20 > 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. K. --Apple-Mail=_9C8EC8D4-1AB1-4F4E-93D5-0F300E710E3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 29, 2021, at 2:05 PM, Michal Va=C5=A1ko <mvasko@cesnet.cz> = wrote:

On Thursday, April 29, 2021 17:14 CEST, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> 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:

=             gs= sapi-with-mic,hostbased,publickey,
=             ke= yboard-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.


K.


= --Apple-Mail=_9C8EC8D4-1AB1-4F4E-93D5-0F300E710E3D-- From nobody Thu Apr 29 12:03:25 2021 Return-Path: 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 3CC003A15B0 for ; Thu, 29 Apr 2021 12:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.onmicrosoft.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 XCVlPvqat_0G for ; Thu, 29 Apr 2021 12:03:19 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2072.outbound.protection.outlook.com [40.107.21.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340D53A4277 for ; Thu, 29 Apr 2021 12:02:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OttHfg3aOWoT/q4o2AAX+gXYo31kDpSpUrs9lHtvj0HeYM5Iw7MDBTfieibhuBSYm/eqYHZ2fELlOm/Qh6ukOzLWJJswrKjx7mMO1w0IVeFeQJa2HtLLel/68ORt5SUjtbM5wNtm2s917bKsJs8P+KI6VE53sTXOLa1HTuTLJd1P5nuSas+J4nqWvY84/uFaBLvGPsrni3sNNXkb2Nwy9b05tMlcTVJlzsX9eSRg3DQFdWURdZg9gwJwg9fCvFSAkvEh1cMU/z/+jpuI5jyNMS53l5GwdqOGkGi2tFwCD3ri9Ix48BUJGyUqX+cSX1EtWmFC+d0HWQU0C+FzDYdqJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dLy3i7YZvqbnhAcAGkt9hLe6hpzzxLOzsOYUEG2GlZo=; b=VaiOWXeVdqeXUayVC7dsXOX+F9EOqfegrtSvtN6fgFzm/7oSIqIU0MJk5CIZRT3ooGaBpySurD7cul6MZM6pYaRdzIrOTuF51CWIwJFqqSORrRPTkXDOC8rDQrKd983+lI6ZauUapsHdCaNzNEjg3EeMM4TeIABdwph41BTFy+Zknh0qRA1G7kRyzD+7AN+VfUolxnkAV30O3/15ZOCldnzlsK3WCXCG48DAI/Oj93M+mv0Ms1nAl58Yr0hfpXFZE4ATBIO6SECRRKcR24Yvy8v7jk3bATpjMHDDaHwcGvxz8uNb7ljAx62gd3xigpvFPhAHG9OTgyxnexzf0arETQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dLy3i7YZvqbnhAcAGkt9hLe6hpzzxLOzsOYUEG2GlZo=; b=sfleGf6Czgs8qe9VZ4p5paIBx3psLkcJGg8gvjRYBjs3W3CliHx2leBvuB4/Px35qxNRMEOfRoT/wsf8Uaj0KIvnxuKziAATbBD22ZMGdwgIg2n6zOXHNJ0xqCAn7GJhOJoi++n1CcyzIwVoXI5hx6C3iByCA7QxOxXOWT7Cg3s= Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1268.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:265::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.25; Thu, 29 Apr 2021 19:02:11 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::fd93:9b33:ac92:ea58%8]) with mapi id 15.20.4087.026; Thu, 29 Apr 2021 19:02:11 +0000 Date: Thu, 29 Apr 2021 21:02:09 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: Michal =?utf-8?B?VmHFoWtv?= , "netconf@ietf.org" Message-ID: <20210429190209.dheo4q2sol5jt473@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Michal =?utf-8?B?VmHFoWtv?= , "netconf@ietf.org" References: <971-608af580-15-2e293dc0@34342692> <010001791eead163-ac714f94-ac4f-455a-adcf-20577ce13dc4-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <010001791eead163-ac714f94-ac4f-455a-adcf-20577ce13dc4-000000@email.amazonses.com> X-Originating-IP: [212.201.44.244] X-ClientProxiedBy: PR3P195CA0017.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::22) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P195CA0017.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.27 via Frontend Transport; Thu, 29 Apr 2021 19:02:11 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 17cd807c-11f0-4101-debc-08d90b414b1d X-MS-TrafficTypeDiagnostic: AM9P190MB1268: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 47BZELCsjS2Z0+OeWKVedAv+oigocqUbIdHiVdGR2g8lOVMcbhlV4rWLghjv7IILm5haGz9GD4/FYYRxd7f57Vx8ElURABgdzTQnuFfIxrRZxZ83YfR5wPFVREzqX84PejNxyLF+/JpBxujQpPEzq3VyHL2yY0dM3onm34P2t1U9Dfv9wb1ZFeHgqy2pJAKkPQ58Avy7DjuIi2dNUUwTUksnNmoXpSD+Z87ZqQekgsNk/aH5ealNEo7l9GthPmEZexfANUBvabDy4ybDn9n4w5RW9Hw9hXPxbQ5dYVMb35elSlox7LyOGqWK1AjDwAC/qimn6T65/Rw7T7loJA6DqXAKQx1mEc2Tf3rBSr9Mn8fl9XT+yY/mrWny59ZLmVckyrX0Zdv7oosu/MD4zh1LXk6IQg1cqbKtjjb7/Q0XpCVfOoUmPYlBmP86WQky0xHPukVujuTvYOzcJUkHkkQzKIXuRHgdaliFVQW8jwA6SXb5lDnhCziAC2Ho1P5WbE9VZQ+ld23kFQHX6s1m8du9WO3WplBPEZ0/aZTj3V87b5ChoZ25QjgXleZUzuMUaPLzVGFQKZWclb/pTxuKNmTrSJjzatGl0S1+pC7iljRlM1Jgp8fZTVxt1HWER1V1ZaFkpF105fODgp0ThHSHr7eW4FvjU7H2AH8O9GfN63HualhWyUQ7tzSMlWTphvEFNmjD7PmV7NuTdjik6eodsrNfqntiohJHcRb0yIGxAmy3Cfw= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(396003)(39830400003)(366004)(346002)(136003)(86362001)(66574015)(26005)(1076003)(16526019)(6496006)(83380400001)(786003)(186003)(316002)(8936002)(52116002)(3450700001)(38100700002)(6486002)(2906002)(478600001)(66476007)(54906003)(5660300002)(8676002)(66946007)(956004)(38350700002)(53546011)(66556008)(4326008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?NE1Vb2d3QkR4VDE2RnVCdUMycnlSL2w0Rnk2SUZCZlZJRHNhcFI4aGp2NlNk?= =?utf-8?B?bHZ3OXp6a3JBcTBEZmJrWkdJUUtPZlRFS0VoOURyZ2djSjZ4ZHR3NFNLVHlj?= =?utf-8?B?VDdINHhBWDl2ZFIrK1gvdmlrTmljc2lFbmFSRFpkQ2t4SDFlZWdiQ0UyNlIw?= =?utf-8?B?VnJkbzFyS3FBcVl5OXlCTktRMVhRNEdoalBFK0c1SEdxeFNDU3FwWDh3QS9Z?= =?utf-8?B?OEk4aHFTZ0NKb3d2QzdjTDgzL1dVWThyUEFYdXRHaTdqT1Y2MWl3YnZMdWtS?= =?utf-8?B?WWNaTWZ0UGNCeEhCdE5oY3g5SFU5RW1QZE0yS3dqN1FDdjNoZGRTVnhXRENE?= =?utf-8?B?TXZ0ZkpsUjFZZ2QwN1hyN0FKR3h2dG03bllQUTdtejlkV012VlZCR1hLMDdO?= =?utf-8?B?cTJ0azRXSDVVWUg4Z0pqZXp0Rm1jMm9LTkdBTEVpckFVZ2NWSVNLdWdEdDVp?= =?utf-8?B?M0tvd1Fvd2dCTjArbkM4QTRUbHBPS000ZXNDRWNteldwOGFoU3dXMEVxSlVq?= =?utf-8?B?aUJyUWZxbVdDOUNoM0NpNERlMExHMCswYklHZ2hhUXUzUkMxMmNwRzFqMlBV?= =?utf-8?B?QVhrWUZKM0l1ek9VZ0NJMG9IVGc2S1RrcVJHNXF1a05KZUNvblo0SlBvTXNX?= =?utf-8?B?TlprNFc1TThDd0Y3c3lUQm5zTUx4REkzdWFvKzJTY1g0QnRraHBIaG45QXUw?= =?utf-8?B?UWxwL1MrZGxreUNTVTdZTWRxV3RDTGNsQ1RnSEZ2RitBZ2xSb1FFZDN4TWth?= =?utf-8?B?blIzMTdlQi9YdmtGNTJEVklOQmZJTG1nbW03MW1uOFZVWVBkUXNMNDRKS1NP?= =?utf-8?B?ZXEyTnd2U1RZY2xiRkhnNDhoaTFsdkdEd0ZvNzdNL3ppaTN3elpNTHNNODk1?= =?utf-8?B?VElXbGZ0RXhsQXQ4Q1ZEOXdCTkt2ZnhERTMyNnpNN0lrNzZhMmNObHNjOXdU?= =?utf-8?B?SHZvdHpRSW8yNzNCZ214SE5idU56RkxOQUo4OWRtVGdDSnU0SkdONVYrV1NH?= =?utf-8?B?Ky85TldwN2FSNzEyeUE2dkNxRDN0a0t6cDVqS2JjQVhlZENucmlMSGwvZmx5?= =?utf-8?B?Vnh2TmVNbHM4WVFpeVNsNi9scURjdE9hd1FiM3d1bXhpQzdqSnFBTlY2WVJG?= =?utf-8?B?bnhTRGJPSHNtQlNQRWdhYURmZE1JZVpOek9QMisrRHM1RHFNUzNjMFpDUFNU?= =?utf-8?B?OFBBQ3k2b0VBeGVCTTR0QUJCQkVtazcrYWFwMzgxd3NMQXpPMTBtdTNMUk5B?= =?utf-8?B?WTdrd2VTay9pSUZzR25qaDErRzhUZDJIWHBDZjBzRVlLYjZ5SWRzTTVtSTNT?= =?utf-8?B?dVpCeng0QmlWbkFUZVZLTkhXOUU2bTB6cFgxaVpNS3M1WUdxS2tOV1lSdmhw?= =?utf-8?B?eXlJWVEzUFdPVzk4NGZwbmFvek5Bc29hUXRpektJbklDL0drYVIxSnJJR2o4?= =?utf-8?B?Q0ZraG1Id1Q1R1l6TXIyejFvNTBlTllLQUJoWC9IR2tPNWsweDM4Zkl2cE1s?= =?utf-8?B?T2o2Z3RkZGs1Qm9PbkFnZVkrM2c1NnlDWmFHMWV6MURWcnJHM2ZYdHZrSmVQ?= =?utf-8?B?dHZVaG96ZUQ1cFQ5UW9KMG1PSEtDTTltaEtCS2F2US9NSzIvK1dVcm13bWVm?= =?utf-8?B?Nnc0RTB1YmszUDFmNmNGUFlCeHJnVW41cEcrcFpRd3pCRVdXMEMxY0tRRWhv?= =?utf-8?B?Ui9pbWxjaHNTRDh5OUdZWGN1SzFXZnJSS3htZmkvaW5PaUtvLyszM1RKVUk4?= =?utf-8?Q?HK4jb37iVuJgVLMKBDXBWgMa8F4VNFVTjbHewUM?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 17cd807c-11f0-4101-debc-08d90b414b1d X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2021 19:02:11.1660 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: eczAoySEmi+Q8dyh6P/fD0yZnmAuq1uYuYrWVWKkr5YgSD1AVivj7B2e5KAoIvZ1Tns00UBpemSUtl4XF24CwiuhXV94/8Qpw8fs5WsAH3w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1268 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 19:03:24 -0000 On Thu, Apr 29, 2021 at 06:36:16PM +0000, Kent Watsen wrote: > > > > On Apr 29, 2021, at 2:05 PM, Michal Vaško wrote: > > > > On Thursday, April 29, 2021 17:14 CEST, Juergen Schoenwaelder 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103
Subject:Re: [netconf] Shepherd review of = draft-ietf-netconf-notification-capabilities
Date:Fri, 2 Apr 2021 21:58:43 = +0200
From:Benoit <benoit@claise.be>
To: Kent Watsen <kent+ietf@watsen.net>, Benoit <benoit@claise.be>
CC: netconf@ietf.org <netconf@ietf.org>