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

[Leif Johansson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
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:
>> -----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.
> 
> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+FWCUACgkQ8Jx8FtbMZncLkgCfapCD+u5r5atcyG1v7b0fTNca
FVMAn0V2cLrHYjhqRMTMzjnsNII1DPzn
=2P16
-----END PGP SIGNATURE-----