Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-04
Leif Johansson <leifj@sunet.se> Wed, 11 April 2012 09:27 UTC
Return-Path: <leifj@sunet.se>
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 B937F21F86F2; Wed, 11 Apr 2012 02:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 LT+oTsYggj5G; Wed, 11 Apr 2012 02:27:19 -0700 (PDT)
Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id E083621F86E2; Wed, 11 Apr 2012 02:27:18 -0700 (PDT)
Received: from [109.105.104.178] (dhcp44.se-tug.nordu.net [109.105.104.178] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q3B9RCS4022687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 11:27:16 +0200 (CEST)
Message-ID: <4F854E70.4060900@sunet.se>
Date: Wed, 11 Apr 2012 11:27:12 +0200
From: Leif Johansson <leifj@sunet.se>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Leif Johansson <leifj@nordu.net>, draft-ietf-netmod-smi-yang.all@tools.ietf.org, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
References: <4F853D62.1090204@sunet.se> <20120411091551.GA26732@elstar.local>
In-Reply-To: <20120411091551.GA26732@elstar.local>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-04
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: Wed, 11 Apr 2012 09:27:19 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/11/2012 11:15 AM, Juergen Schoenwaelder wrote: > On Wed, Apr 11, 2012 at 10:14:26AM +0200, Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> >> Hi, >> >> 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. >> >> The document specifies a translation between SMIv2 (and by >> reference to RFC 3584, SMIv1) and YANG. YANG is the information >> model language used in NETCONF. >> >> This draft is outside my subject-matter expertise but the core >> security issue seems to be around translation of the SMIv2 >> MAX-ACCESS macro to YANG. Since YANG doesn't define any >> corresponding element an extension to YANG is defined. >> >> However there doesn't seem to be any requirement to implement >> that extension. The security considerations section refers the >> reader to the security considerations sections for YANG, NETCONF, >> SMI etc but claims that "The translation itself has no security >> impact on the Internet.". >> >> I would have liked to see a clear normative statement to the >> effect that if you relied on MAX-ACCESS in the SMIv2 version of a >> MIB then you MUST implement the YANG extension for SMI and that >> the NETCONF implementation used MUST respect the resulting >> smiv2:max-access statements. > > Hi, > > the MAX-ACCESS in the SMIv2 really has nothing to do with access > control. See section 7.3 of RFC 2578 for the details. Also note > that the SMiv2 to YANG mapping is readonly, that is even if the > SMIv2 MAX-ACCESS is "read-write" or "read-create", the > corresponsing YANG leaf is read-only. > > Note that access control in the SNMP world is handled by VACM (RFC > 3415) and in the NETCONF world by NACM (RFC 6536). > > /js > As I said this is somewhat outside my comfort-zone but I don't understand how MAX-ACCESS isn't related to access restrictions given the security considerations section of rfc 3584. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+FTnAACgkQ8Jx8FtbMZndR3wCgkVwon5aZb8HOCEW5fUWsy97C 4lgAn3VfT6Xw+3T48GUuLgffHF7GlEo9 =LZeH -----END PGP SIGNATURE-----
- [secdir] secdir review of draft-ietf-netmod-smi-y… Leif Johansson
- Re: [secdir] secdir review of draft-ietf-netmod-s… Juergen Schoenwaelder
- Re: [secdir] secdir review of draft-ietf-netmod-s… Leif Johansson
- Re: [secdir] secdir review of draft-ietf-netmod-s… Juergen Schoenwaelder
- Re: [secdir] secdir review of draft-ietf-netmod-s… Leif Johansson
- Re: [secdir] secdir review of draft-ietf-netmod-s… Benoit Claise
- Re: [secdir] secdir review of draft-ietf-netmod-s… Juergen Schoenwaelder
- Re: [secdir] secdir review of draft-ietf-netmod-s… Benoit Claise