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

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Apr 2012 10:14:26 +0200

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.

	Cheers Leif

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Apr 2012 11:15:51 +0200

On Wed, Apr 11, 2012 at 10:14:26AM +0200, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Hi,
> 

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Apr 2012 11:27:12 +0200

On 04/11/2012 11:15 AM, Juergen Schoenwaelder 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.
>> 
>> 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,
> 
> 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.
> 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Apr 2012 11:42:34 +0200

> 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

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Apr 2012 12:08:37 +0200

On 04/11/2012 11:42 AM, Juergen Schoenwaelder wrote:
>>>> 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.
>>>> 
>>>> 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.".
>>>> 
>>>> 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
>>> 
>> 
> 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:
> 
> objects.  Sometimes there are specific conformance definitions
> that specifically allow for such implementations. Sometimes 
> * 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.
> 
> 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:
> 
> 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?

---

From: Benoit Claise <[email-masked]>
Date: Wed, 25 Apr 2012 15:26:32 +0200

Hi Juergen,
> explanation to the security considerations?
Do you plan on adding such an explanation in the draft, or at least give 
pointers to the different RFCs?

Regards, Benoit (trying to evaluate if/how we can close this issue)
> -----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-----
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Apr 2012 15:33:37 +0200

On Wed, Apr 25, 2012 at 03:26:32PM +0200, Benoit Claise wrote:

> Do you plan on adding such an explanation in the draft, or at least
> give pointers to the different RFCs?

Benoit,

I made some changes in the -05 version in the hope that this was
sufficient. In particular, I am spelling out that the RFCs containing
the SMIv2 data models contain a discussion of the sensitivity of the
various objects and I added an explicite reference to the NETCONF
access control model.

/js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 25 Apr 2012 15:46:48 +0200

Thanks Juergen!

Regards, Benoit