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

Leif Johansson <> Wed, 11 April 2012 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA7B811E8086; Wed, 11 Apr 2012 03:08:48 -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=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0q3GeMaBsH6P; Wed, 11 Apr 2012 03:08:48 -0700 (PDT)
Received: from ( [IPv6:2001:948:4:1::66]) by (Postfix) with ESMTP id 83C6621F866A; Wed, 11 Apr 2012 03:08:43 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q3BA8b4Z017721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 12:08:40 +0200 (CEST)
Message-ID: <>
Date: Wed, 11 Apr 2012 12:08:37 +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> <> <20120411094234.GA26959@elstar.local>
In-Reply-To: <20120411094234.GA26959@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 10:08:48 -0000

Hash: SHA1

On 04/11/2012 11:42 AM, Juergen Schoenwaelder wrote:
> On Wed, Apr 11, 2012 at 11:27:12AM +0200, Leif Johansson wrote:
>> 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.
> The MAX-ACCESS documents whether an object from a data modeling 
> perspective is in principle writable/creatable or always readonly.
> In other words, it documents that maximum possible access to an
> object from a data modeling perspective. There are objects (e.g.,
> counters) that are inherently readonly and hence have a MAX-ACCESS
> readonly. Other objects may in principle be writable from a
> modeling perspective. There are two ways to constrain a MAX-ACCESS
> in the SNMP world:
> * First, implementation may implement writable objects as readonly 
> objects.  Sometimes there are specific conformance definitions
> that specifically allow for such implementations. Sometimes 
> implementations do this on their own choice, ideally documented in 
> so call AGENT-CAPABILITIES (a machine readable documentation of 
> deviations from a conformance definition).
> * Second, an access control model (with a collection of access
> control rules) is used to determine at runtime whether the
> MAX-ACCESS should be restricted.
> The MIB security considerations boilerplate commonly used in MIB 
> documents requires that MIB authors document which objects may be 
> criticial to protect. This is essentially advise to people
> deploying MIB modules on how to construct their runtime access
> control rules.
> Coming back to the SMIv2 to YANG translation, it turned out that
> for various other technical reasons, the translation to YANG is
> readonly (or config false as we say in the YANG community). Hence,
> even if an SMIv2 object has a MAX-ACCESS of readwrite, the
> corresponding YANG leaf will be config false. Hence, the current
> text in the security considerations says:
> 13.  Security Considerations
> This document defines a translation of SMIv2 MIB modules into YANG 
> modules, enabling read-only access to data objects defined in
> SMIv2 MIB modules via NETCONF.  The translation itself has no
> security impact on the Internet.
> Does this help?
> /js

It helps me right now but how do we help future readers? I jumped to
this conclusion just by tracing some of the security considerations
sections. Perhaps you should add a a condensed version of your excellent
explanation to the security considerations?
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -