[secdir] Secdir review of draft-ietf-netconf-system-notifications-06

Brian Weis <bew@cisco.com> Tue, 29 November 2011 00:05 UTC

Return-Path: <bew@cisco.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 B0B0011E80CE; Mon, 28 Nov 2011 16:05:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhu8aVsjS+fW; Mon, 28 Nov 2011 16:05:09 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EA84911E80CA; Mon, 28 Nov 2011 16:05:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=1889; q=dns/txt; s=iport; t=1322525108; x=1323734708; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=Bzz8RQfmafnvL1Wza7a8bSrVju1WoOFQOa1gLVHs+Uk=; b=FboAM898zvuBsjbK8suxlJogrzsYZomT4rT/ef/BNJ5e5r5yH51Tr9IP JabQqtXyXb6BJ4ezaOnHox/kirlsIePDaErshqj9nW2dVqwDGsy1Ldsnx zFiWC7WauWsyrhaWS44qw4+7SictPk2Z9nH+lKLXKectyAHR9PBKUgmeb k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAIIh1E6rRDoJ/2dsb2JhbABDqnaBBYILASc9AoE+ATSgNQGeYIl/YwSIIYwpkiw
X-IronPort-AV: E=Sophos;i="4.69,587,1315180800"; d="scan'208";a="14927573"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 29 Nov 2011 00:05:07 +0000
Received: from dhcp-128-107-151-81.cisco.com (dhcp-128-107-151-81.cisco.com [128.107.151.81]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAT057DI013621; Tue, 29 Nov 2011 00:05:07 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 28 Nov 2011 16:05:07 -0800
Message-Id: <A9BE257F-595A-4650-A7AA-571B8A2235A7@cisco.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-netconf-system-notifications.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-netconf-system-notifications-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 29 Nov 2011 00:05:09 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. Events reported include change of system configuration, start or stop of of a NETCONF client, and the like. These are important notifications for the purposes of accounting and auditing.

I have two comments on the Security Considerations text:

1) The first paragraph indicates that SSH is mandatory-to-implement for the transport layer and cites RFC 6242 ("Using the NETCONF Protocol over Secure Shell (SSH)". This is certainly good and acceptable, but I'm not sure where the statement is made that says RFC 6242 MUST be implemented as part of a NETCONF implementation. It would be good to cite that RFC as well.

2) The second paragraph wisely states that read access to the data nodes described in this memo should be controlled. It would be helpful to give some advice how the control can be done. For example, this could be an authorization step by the SSH server as part of authenticating a client. Or it could be true because authentication credentials known by server are only given to users who are authorized to have read access. The first paragraph of RFC 62642's Security Considerations discusses this a bit and seems to imply the latter authorization model. If that's the intention here, a statement recommending giving out authentication credentials only to users/devices authorized to read the NETCONF notifications would be sufficient.

Brian