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

[Glenn Mansfield Keeni <[e-mail]>]

Hi,
 > 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?
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:
> Hi -
> 
> 
> On 9/30/2018 5:59 AM, Glenn Mansfield Keeni wrote:
>>
>> Hi,
>>  >         What
>>  >         is the point of limiting read access and then sending the
>>  >         information in the clear?
>> 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
>>  > 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.
> ...
> 
> 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