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

From: Glenn Mansfield Keeni <[email-masked]>
Date: Sat, 29 Sep 2018 15:52:52 +0900

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.

Please advise on how to proceed on this matter.

Thanks,
Glenn

---

From: Randy Presuhn <[email-masked]>
Date: Sat, 29 Sep 2018 10:56:30 -0700

Hi -

> mailing list on this matter. There is no disagreement

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

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Sun, 30 Sep 2018 21:59:05 +0900

Hi,
 >         What
Total agreement. Sending info in the clear is by default NG and must
be strongly discouraged.
It will help to have some proposed replacement text for

Glenn

---

From: Randy Presuhn <[email-masked]>
Date: Sun, 30 Sep 2018 08:40:25 -0700

Hi -

>  >        objects when sending them over the network via SNMP.
...

As I wrote previously, this would be editorially tricky since the
paragraph currently conflates "sensitive" (which I take to mean
"that which should be protected from disclosure") with "vulnerable"
(which I take to mean "that which should be protected from
modification").  It *is* possible to have something which one wants
to protect from modification, but there's no need to protect it from
disclosure.  For example, consider a hostname.  Are we willing to
do major surgery on this paragraph, probably splitting it into two,
and thus affecting the structure of these security considerations?

Randy

---

From: Warren Kumari <[email-masked]>
Date: Sun, 30 Sep 2018 14:33:22 -0400

> Please advise on how to proceed on this matter.

I'm obviously not Igans (he's got more, and better hair), but this is
clearly a nit that is easy to address.
I propose we fix this nit now, and the larger discussion can continue -
'tis trivial to update the boilerplate again once the larger discussion has
gelled.

Sound reasonable? I'll let Ignas to make the call (it's more on his side of
the house than mine).

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Mon, 1 Oct 2018 11:15:17 +0900

Hi,
 > and thus affecting the structure of these security considerations?
I would suggest that we take this in 2 steps.
First, fix the (now) obvious nit.
+--------------------------------------------------------------------+
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.
+---------------------------------------------------------------------+
Next, discuss and arrive at the decision (and maybe text too) on whether
we are willing to do major surgery etc. I agree that in the current form
(even with the nit-fix) the security considerations remain incomplete.

Glenn

On 2018/10/01 0:40, Randy Presuhn wrote:
>>  >         What
>>  >         is the point of limiting read access and then sending the
>>  >         information in the clear?
>>  > 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.
> ...
>

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Mon, 1 Oct 2018 11:21:35 +0900

Hi,
 > I propose we fix this nit now, and the larger discussion can
 > continue - 'tis trivial to update the boilerplate again once
 > the larger discussion has gelled.
 >
 > Sound reasonable? I'll let Ignas to make the call (it's more
 > on his side of the house than mine).

Absolutely! Thanks.

Glenn