Subject: Re: Alarm MIB security issues

From: Randy Presuhn <[email-masked]>
Date: Mon, 29 Apr 2002 16:09:47 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Sun, 28 Apr 2002 21:57:36 -0700
> To: Randy Presuhn <[email-masked]>, [email-masked]
> From: "David T. Perkins" <[email-masked]>
> Subject: Re: Alarm MIB security issues
> In-Reply-To: <[email-masked]>
...
> I'm having problems following the below. However, it appears that it
> is reusing a "BROKEN" design pattern found in RFC 3014. I HOPE THAT
> THIS BROKEN DESIGN PATTERN IS NOT USED IN OTHER MIB MODULES.
> This is marked below..
> 
> At 04:30 PM 4/25/2002 -0700, Randy Presuhn wrote:
...
> VVVVVVVV
> >   When an application creates an alarm model (indexed in part by the
> >   alarm list name) the security credentials of the creator remain
> >   associated with that alarm model and constrain what information is
> >   allowed to be placed in the active alarm table, the active alarm
> >   variable table, the cleared alarm table, and the ITU alarm table.
> >   When processing locally-generated Notifications, the managed
> >   system MUST use the security credentials associated with
> >   that each alarm model respectively, and MUST apply the
> >   same access control rules as described for a Notification
> >   Originator in [RFC2573].
> 
> ^^^^^^^^
> This is just totally broken. Why? Because the information is "hidden".
> A manager cannot look at the created rows and figure out the what
> is the behavior without knowing the hidden values. Also, if one wanted
> to "save the configuration" and then "restore it", it would be impossible.

Writing as WG chair...

Like it or not, there are already several standards-track RFCs
with similar properties, e.g.:
  RFC 2982, Expression MIB
  RFC 2981, Event MIB
  RFC 3014, Log MIB,
  RFC 3165, Script MIB
  RFC 3231, Schedule MIB

Several years ago, we had lengthy discussions in disman WG
meetings regarding the pros and cons of "explicit delegation"
rather than the path that we've taken.  Though I personally
believed (and still believe) explicit delegation to be both
more powerful and ultimately easier to understand, the working
group did not, and the consistent direction in the current
RFCs and I-Ds reflects that rough consensus.

Though I might personally very much like to see things working
on a foundation of explicit delegation rather than the current
implicit model, I don't see anything approaching a concensus
to make such a potentially disruptive change, and nothing
from implementation experience to date to suggest that what
we currently have is unworkable.

As a technical contributor, I'd like to remind you that several
objects in RFC 2574 have the same "bug"/"feature" regarding the
ability to use SNMP to extract a system's configuration.

> Also, say that you used SNMPv3 with USM and auth/priv to create the
> row. This one mean that only notifications that were allowed to be
> sent with auth/priv could result in additions to the active table.
> This is just not correct.
...

As a technical contributor, I believe this is perfectly reasonable.
No sane security administrator would circumscribe the auth/priv
views more narrowly than noauth/nopriv.

More importantly, notifications which are only allowed on the
wire in auth/priv form should not go into "public" active alarm
tables.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 29 Apr 2002 19:01:22 -0700

HI,

>ability to use SNMP to extract a system's configuration.

Other than the keys, what objects have the attribute that you can
not retrieve values set via SNMP so that you can restore the
configuration via SNMP?

Or were you talking about another attribute?

Regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 29 Apr 2002 19:12:23 -0700

HI,

Maybe an often repeated phrase is appropriate here...
Those that do not study history repeat the same mistakes.

Now whether or not what was done in the MIBs
that you specified were or were not appropriate
is something for someone else to review.
However, in my review of the LOG MIB (RFC 3014),
the capture and use of "hidden" credentials creates
more problems than it solves.

Lets fix the LOG MIB, and use that experience to
do a better job of future MIBs (like the ALARM MIB)
instead of reusing patterns that have problems.

The configuration save/restore and auditing is one problem,
but the model that one has to use the same security name,
security model, and security level in creating the 
"control table entries" that you want for the 
"data table entries" is just silly.

Regards,
/david t. perkins