Re: [MIB-DOCTORS] Fix of Security Guidelines for IETF MIB Modules

[Randy Presuhn <[e-mail]>]

Hi -

On 9/28/2018 11:52 PM, Glenn Mansfield Keeni wrote:
> Warren,Ignas,
>         Hi. The Security Guidelines for IETF MIB Modules
> needs a fix in the text that is generally used verbatim
> in MIB documents.
> The proposed fix is
> 
> OLD: Some of the readable objects in this MIB module
>       (i.e., objects with a MAX-ACCESS other than
>        not-accessible)
> NEW: Some of the readable objects in this MIB module
>       (e.g., objects with a MAX-ACCESS other than
>        not-accessible)
> 
> The above is a significant nit. It appears in the
> Security Considerations sections section of every
> MIB document.
> 
> There has been some discussion on the IETF MIB-DOCTORS
> mailing list on this matter. There is no disagreement
> on the proposed fix.

In the scope of the document under consideration at the
time, I think that fix was ok, but in the context of a
boilerplate update I think we'd need to do better.

For those who missed the original discussion, the issue is
that the values of "not-accessible" objects can
    (1) be sensitive
    (2) be revealed as index values

Consider, as a trivial, made-up example, a table indexed
by user name.

OLD:  Some of the readable objects in this MIB module (i.e., objects
       with a MAX-ACCESS other than not-accessible) may be considered
       sensitive or vulnerable in some network environments.

NEW:  Some of the objects in this MIB module may be considered sensitive
       or vulnerable in some network environments.  This includes INDEX
       objects with a MAX-ACCESS of not-accessible, and any indices from
       other modules exposed via AUGMENTS.

But, if we are going to touch the boilerplate, I wouldn't stop there.
I think the next sentence brings its own related problems.

OLD:  It is thus important to control even GET and/or NOTIFY access to
       these objects and possibly to even encrypt the values of these
       objects when sending them over the network via SNMP.

The issues I see with this are:

    (1) in the case of objects used as indexes, controlling access to
        them via VACM is *not* just a matter of controlling access to
        the objects themselves, but of controlling access to all
        objects using them as indexes, including usage via AUGMENTS.

    (2) index values may be leaked by "pointer" objects of type
        OBJECT IDENTIFIER.  If VACM is being used for access control,
        the rules have to be formulated in terms of the pointer, not
        the set of things it might point to.  That problem is outside
        the scope of the module whose objects are being pointed to,
        but it's still a problem that needs to be addressed in any
        module defining such pointers.

    (3) even without considering the case of indexes, I would argue that
        if something is sensitive enough to merit limiting read access,
        in any sane security regime it will also merit encryption.  What
        is the point of limiting read access and then sending the
        information in the clear?

I'll concede that there are cases where limiting *write* access does not
imply a need for encryption, but this paragraph conflates sensitive and
vulnerable information.  It might make sense to split the paragraph into
two, one identifying the information for which disclosure is an issue,
and another identifying the information for which creation / deletion /
modification is an issue.

Randy