Re: [secdir] secdir review of draft-ietf-netmod-smi-yang-04

Leif Johansson <> Wed, 11 April 2012 09:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B937F21F86F2; Wed, 11 Apr 2012 02:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LT+oTsYggj5G; Wed, 11 Apr 2012 02:27:19 -0700 (PDT)
Received: from ( [IPv6:2001:948:4:1::66]) by (Postfix) with ESMTP id E083621F86E2; Wed, 11 Apr 2012 02:27:18 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (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: <>
Date: Wed, 11 Apr 2012 11:27:12 +0200
From: Leif Johansson <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Leif Johansson <>,, "" <>, "" <>
References: <> <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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Apr 2012 09:27:19 -0000

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:
>> 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
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -