Re: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order

"Wubo (lana)" <lana.wubo@huawei.com> Wed, 20 November 2019 06:09 UTC

Return-Path: <lana.wubo@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F414120802 for <opsawg@ietfa.amsl.com>; Tue, 19 Nov 2019 22:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 uKfIUHhg1RQu for <opsawg@ietfa.amsl.com>; Tue, 19 Nov 2019 22:09:07 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 29DDF1202DD for <opsawg@ietf.org>; Tue, 19 Nov 2019 22:09:07 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B07BE4762283742501C6 for <opsawg@ietf.org>; Wed, 20 Nov 2019 06:09:05 +0000 (GMT)
Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 20 Nov 2019 06:09:05 +0000
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 20 Nov 2019 14:09:03 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1713.004; Wed, 20 Nov 2019 14:09:03 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>, john heasley <heas@shrubbery.net>
CC: opsawg <opsawg@ietf.org>
Thread-Topic: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order
Thread-Index: AdWfZnpf2FK4lf/UReWpHUHY7eBgiA==
Date: Wed, 20 Nov 2019 06:09:02 +0000
Message-ID: <ff2f7d40bd404f89acde04e9d5c33da2@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.37.215]
Content-Type: multipart/alternative; boundary="_000_ff2f7d40bd404f89acde04e9d5c33da2huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/w6qu1fHtGhIyBj_VucIXu0Mju0w>
Subject: Re: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2019 06:09:09 -0000

Hi Joe,

Thanks for the suggestion and also the guidance from Lada and other YANG doctors.


With this ‘ietf-system-tacacsplus’ module level ‘must-statement’, rather than the system level, I will update the TACACS+ YANG draft in next release.

Thanks,
Bo

发件人: Joe Clarke (jclarke) [mailto:jclarke@cisco.com]
发送时间: 2019年11月20日 13:30
收件人: john heasley <heas@shrubbery.net>; Wubo (lana) <lana.wubo@huawei.com>
抄送: opsawg <opsawg@ietf.org>
主题: Re: [OPSAWG] re opsawg-tacacs-yang & ietf-system user-authen-order




On Nov 19, 2019, at 22:17, john heasley <heas@shrubbery.net<mailto:heas@shrubbery.net>> wrote:

Regarding the question, on the second to last page of the opsawg-tacacs-yang
presentation slides, about the must in model ietf-system, which I believe was
whether to add a must for tacacs, remove the must for radius, or do nothing;
that must seems wrong to me.

I would expect the system to react no differently to missing sever
configuration than to a list of servers that all fail to respond.  Some
vendors have done this historically in cli.

Whether ietf-system should be changed, I do not know it is worth the effort.
If the WG agrees that its existence is wrong, that might be another question
for yang doctors.

Lada replied on YANG docs with a suggestion for the T+ module authors.  While we can’t affect the authentication-order node, the tacacsplus container could be defined like:

augment "/sys:system" {
 container tacacs {
   must "not(derived-from-or-self("
      + "../sys:authentication/sys:user-authentication-order, 'tacacs')"
      + "or server";
   list server {
      ...
   }
 }
}

In this manner, T+ can provide enforcement.  Lada also mentioned that this would have been a better way of handling RADIUS in ietf-system.  Certainly this could be an item for a .bis, but not sure if this alone is worth taking on that work.

Joe