Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-yang-03

"Wubo (lana)" <lana.wubo@huawei.com> Mon, 11 May 2020 03:01 UTC

Return-Path: <lana.wubo@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60D83A0437; Sun, 10 May 2020 20:01:29 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 IjvquRjL1Mzq; Sun, 10 May 2020 20:01:28 -0700 (PDT)
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 787883A041C; Sun, 10 May 2020 20:01:28 -0700 (PDT)
Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E6B10D5CE06ECD38DF83; Mon, 11 May 2020 04:01:25 +0100 (IST)
Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Mon, 11 May 2020 04:01:25 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 11 May 2020 11:01:23 +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.1913.007; Mon, 11 May 2020 11:01:23 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "opsawg@ietf.org" <opsawg@ietf.org>, "draft-ietf-opsawg-tacacs-yang.all@ietf.org" <draft-ietf-opsawg-tacacs-yang.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-opsawg-tacacs-yang-03
Thread-Index: AdYlq1cMY6ppYXBtRRaWzpDXQ13f2g==
Date: Mon, 11 May 2020 03:01:23 +0000
Message-ID: <b4d8a3edbdf14560996c9395880bffc3@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.83]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/l4PUhNQyiPas0JAdQxujSWld2Dk>
Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-yang-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2020 03:01:30 -0000

Hi Yaron,

Thanks for the review. Please see inline.

Regards,
Bo

-----邮件原件-----
发件人: Yaron Sheffer via Datatracker [mailto:noreply@ietf.org] 
发送时间: 2020年5月9日 1:08
收件人: secdir@ietf.org
抄送: opsawg@ietf.org; draft-ietf-opsawg-tacacs-yang.all@ietf.org; last-call@ietf.org
主题: Secdir last call review of draft-ietf-opsawg-tacacs-yang-03

Reviewer: Yaron Sheffer
Review result: Has Nits

This document defines a YANG module for the configuration of TACACS+ clients.

The document is short and straightforward, and I only have one significant comment.

* I am not familiar with common security practices for the devices covered by this protocol. But I am wondering, should the "shared-secret" field be made optional, so that it can be entered "out of band" in applications that prefer not to keep it stored in the YANG configuration store and available to network management tools?
[Bo] The "shared-secret" node is indeed sensitive. But there are two main reasons for defining as mandatory. 1) The TACACS+ protocol requires that the secret must be configured.  
2) YANG model can use NACM (RFC8341) to ensure node security. The "shared-secret" adds security tagging "nacm:default-deny-all" to restrict only initial device access and some recovery session.

Additionally, the definition follows the current System model (RFC7317) , as TACACS+ model is an augmentation of the System model. The definition of the "shared-secret" in the RADIUS authentication of the System model is mandatory and YANG extension "nacm:default-deny-all" is used to protect. 

Perhaps some addition text could help:
/system/tacacsplus/server/shared-secret:  Access to this node is considered sensitive and therefore has been restricted using the "default-deny-all" access control defined in [RFC8341].


* Not a security comment: the YANG module includes a reference to draft-ietf-opsawg-tacacs-18, but I assume that you'll want to replace it with the RFC number for that draft once it is published. Yet I don't see an RFC Editor note mentioning that.
[Bo] OK, will add in the next revision.

* It is confusing that "messages-received" is for messages received by the server, and "errors-received" is for errors received *from* the server.
[Bo] Thanks, will correct to "from" the server to keep consistency.