RE: Updating the MIB security guidelines

["C. M. Heard" <heard@pobox.com>]

On Tue, 31 Dec 2002, Randy Presuhn wrote:
> > > And even valus of not-accessible index objects can be retrieved by
> > > reading some column and unpacking the index...
> > > 
> > I understand that, but that is implicit if you get access to 
> > an accessible column.
> >
> > Are you saying that we should add something about this?
> 
> I think the point is that in some cases, even knowledge of the
> existence of a row can be sensitive information.  For example,
> consider a table indexed by user id.  In such a case, that
> MIB's security considerations section should probably have
> words to the effect that in some environments, the user names
> are themselves sensitive, and that consequently, even though
> the other information in the table might not of itself be
> sensitive, access to the table might need to be restricted.

I'm not sure it's really necessary, but if you insist, we could fix
this too by changing the words "encrypt the values" to "encrypt the
values and names" in the third setion.  It would then say:

-- for all MIBs you must evaluate

   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.  It is thus
   important to control even GET and/or NOTIFY access to these objects
   and possibly to even encrypt the values and names of these objects
   when sending them over the network via SNMP.  These are the tables
   and objects and their sensitivity/vulnerability:

    <list the tables and objects and state why they are sensitive>

I think this covers the situation described above because the sensitive
user id can be revealed if, and only if, it either appears in the value
or the name of some readable object(s).  Its appearance is why those
object(s) would be sensitive or vulnerable.  The directive to <list the
tables and objects and state why they are sensitive> should take care
of the rest.

//cmh

P.S. I hope that this does not start a discussion about the meaning of
the phrase "values and names of these objects" ... it of course means
the same thing as "value and name fields of the varbinds corresponding
to these objects" ... I hope we don't need to go to _that_ extreme in
these guidelines.