Subject: Re: Alarm MIB security issues

From: Randy Presuhn <[email-masked]>
Date: Tue, 30 Apr 2002 11:22:52 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Mon, 29 Apr 2002 19:12:23 -0700
> To: [email-masked]
> From: "David T. Perkins" <[email-masked]>
> Subject: Re: Alarm MIB security issues
> In-Reply-To: <[email-masked]>
...
> However, in my review of the LOG MIB (RFC 3014),
> the capture and use of "hidden" credentials creates
> more problems than it solves.

And the problems are?
   1) ability of a third party to save and restore
      a configuration (is there any agreement that
      this is a requirement?)
   2) ?

> 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 WG chair has been requesting feedback on the log MIB
for well over a year.  This is the first time that anyone
has claimed that the credential mechanism posed any sort
of a problem, so far as I know.  There are *no* counter-
proposals on the table.  Your complaints might be taken
more seriously if accompanied with a credible solution.

> 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.
...

Thank you for the precise characterization of your viewpoint.
Do you think you could make a constructive proposal?
What should we do to prevent active alarms and logs from
giving inappropriate access to information, if not the
common approach taken by this WG in its other products?

 ------------------------------------------------------
 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: Tue, 30 Apr 2002 12:38:39 -0700

HI,

Randy - I think you have forgotten about the work that Steve Moulton
and I have done. Steve has been unavailable to review the last
update, and, thus, I have not sent it to the list. However, I have
sent it to RamK, but have not yet gotten any feed back from him.

First, lets review the security issues, which are:
1) one wants only notifications in the named logs that were sent to
   a specific management target. Those notifications must "pass" the
   ACL check as described in RFC 2573 for notification distribution.
2) one wants a named log to be viewed only by the managers that
   have the appropriate credentials as specified by the VACM
   configuration for the named log.

Moving on, to answer your question about the problems of the    
RFC 3014 due to the hidden credentials, these include:
1) cannot do a config save/restore
2) cannot do security audit (since you cannot see the "hidden credentials",
    you cannot determine if the control entries match your security policy)
3) currently, the credentials used for the activation of a control table
   entry are used for the credentials used for determining whether or
   not to add a notification to the log. However, these are separate
   operations. The current approach forces them to be the same.

Note, there are other problems with RFC 3014, including:
1) confusion about engineIDs in the definition
2) no clean separation between usage in a "managed system" and
   a "mid-level manager"
3) efficiency of usage (that is, determining if new notifications
   have been added to a log, and then retrieving them)
4) confusion as to where in the notification distribution system
   as described in RFC 2573 where the "flow of notifications" is
   "tapped" (note, the tap point appears different for the null
   named log than for the named logs)
and I've probably forgotten a few....

As to implementation, I'm presently working with the developers at
cisco (who support only a "null named log") and the developers
at RiverStone (who support for both the "null named log"
and "named logs") to create some tests that are easy to configure
and run to determine if the behaviors of each implementation
are identical. Also, I'm trying to determine if the behaviors are
useful by talking with application developers.
Note, that if there are other implementations of RFC 3014 or suggestions
for tests, please contact me. Also, if anyone is writing a management 
application to use RFC 3014, please contact me. (Of course, Randy
would like implementation reports on the mailing list if this
is possible.)

So Randy - there is much work that has taken place. It's not on
the list, because its not at that point yet. 

>> "data table entries" is just silly.

Maybe I deserved the following sarcasm for calling the current
mechanism "just silly". If personal attacks on me are what it
takes to solve the problem, then fine. However, I believe
the below is more words of frustration than a personal attack.

> Randy Presuhn          BMC Software, Inc.  1-3141

Regards,
/david t. perkins