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: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-----