RE: FW: Updating the MIB security guidelines

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Mike... this was on my todo for the Holiday season.
Thanks for reminding me ;-)

Inline
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: vrijdag 27 december 2002 21:14
> To: Wijnen, Bert (Bert)
> Cc: mibs@ops.ietf.org
> Subject: Re: FW: Updating the MIB security guidelines
> 
> 
> Bert,
> 
> http://www.ops.ietf.org/security.html still has the old

yes, needs to be fixed.

> MIB security guidelines, which point to the now-obsoleted
> RFC 2474 and RFC 2475.  We need to get this replaced ASAP;
> otherwise MIB authors are likely to put out-of-date stuff
> in their documents.  It would also be a very good idea to
> announce the new security guidelines and boilerplate on
> the IETF-Announce list as well as here.
> 
> With certain global editing changes (s/2570bis/3410/,
> s/claise/clause/, s/inluding/including/) the template
> that you posted previously (attached below) would be
> OK; 

OK, your fixes seem fine sofar

> but there is one other change that I think would
> improve it a lot.  Juergen made the point earlier:
> 
> >>>>>> On Wed, 6 Nov 2002, Juergen Schoenwaelder wrote:
> > > -- for all MIBs you must evaluate
> > > 
> > >    There are a number of managed objects in this MIB module with a 
> > >    MAX-ACCESS claise of read-only and/or notify-only. Some of these
> [      [ .... ] ]
> > 
> > I think the evaluation which readable information is sensitive also
> > applies to read-write and read-create objects since they are readable
> > as well. So probably it is simpler to just say that the following
> > evaluation has to be done for _all_ managed objects.
> 
> I agree with that.

But you may have noticed that I answered:

   That is what we indeed had in the old boiler plate, but I often found
   that people would not differentiate between the read and write
   sensitivity/impacts and vulenerabilities. If I remember well then
   the security ADs did make a remark about that quite a while ago too.

   But maybe I can come up with some text that encourages to do it right
   in just this place (instead of having it at different places).

>  So may I suggest that you consider the following language instead:
> 
> -- for all MIBs you must evaluate
> 
>    Some of the readable objects in this MIB module may be considered
>    sensitive or vulnerable in some network environments.  It is thus
>    important to control even GET access to these objects and possibly
>    to even encrypt the values 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>
> 
> Note that "readable objects" covers read-write and read-create objects
> as well as read-only objects, and so accomplishes Juergen's objective.
> 
OK, that would work for me. Am I assuming correct here that the
two sections on read-create/read-write and on read-write also stay
in your proposal?

> One last point:  in many cases it's not possible to single out any
> parrticular readable MIB objects as being especially sensitive, but
> it is still the case that some users will not want the information
> in the MIB module revealed indiscriminately.  I hope that in such cases
> it will be considered acceptable within the guidelines to say something
> like this (the following example is intended for the Ethernet 
> WIS MIB):
> 
>    The readable objects in this MIB module may be considered sensitive
>    in some environments since, collectively, they provide information
>    about the performance of Ethernet interfaces and can reveal some
>    aspects of their configuration.  In such environments it is important
>    to control even GET access to these objects and possibly to even
>    encrypt the values of these objects when sending them over the
>    network via SNMP.
> 
I think Wes made a similar comment also.
I think this would be fine. After all, the idea is that this is a guideline.

Should we add some text about that? I worry (again) that people will take
the easy way out and always do something as a bovem and that is exactly what
we do NOT want. If at all possible (and where it makes sense), we want
authors/editors to be EXPLICIT as to which pieces of the information are
senstitive and why.

Let me know if the above sounds good and I can do a new rev of the
complete text.

Bert