Subject: Alarm MIB security issues

From: Randy Presuhn <[email-masked]>
Date: Thu, 25 Apr 2002 16:30:31 -0700 (PDT)

Hi -

As a technical contributor, I think some security issues in
draft-ietf-disman-alarm-mib-06.txt need to be addressed.

   1) To prevent the alarm MIB from becoming a backdoor for
      circumventing access control on information carried
      in notifications.  Something similar to the language
      in RFC 3014 section 2.1.2 is needed.  Proposed text:

   Security for alarms is awkward since access control for the objects
   in the underlying notifications can be checked only where the
   notification is created.  Thus such checking is possible only for
   locally-generated notifications, and even then only when security
   credentials are available.

   For the purpose of this discussion, "security credentials" means
   the input values for the abstract service interface function
   isAccessAllowed [RFC2571] and using those credentials means
   conceptually using that function to see that those credentials
   allow access to the MIB objects in question, operating as for a
   Notification Originator in [RFC2573].

   The Alarm MIB has the notion of a named alarm list.  By using
   alarm list names and view-based access control [RFC2575] a network
   administrator can provide different access for different users.
   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].

   The managed system SHOULD NOT apply access control when
   processing remotely-generated Notifications using the alarm
   models.  In those cases the security of the information
   in the alarm tables SHOULD be left to the normal, overall
   access control for those tables.

 -=-=-=-=-=-

To fit this in with the overall processing flow established by
the work on RFC 3014, I think some additional changes to the
diagram in section 3.3 of draft-ietf-disman-alarm-mib-06.txt
are necessary.  Thes will:

   2) To permit implementations to take full advantage of
      the RFC 2573 filtering infrastructure

   3) To keep the semantics of alarmListName in this mib and
      nlmLogName in RFC 3014 consistent.

The modified diagram would look something like:

                     |
                     |<----------------------------------------------+
                     |                                               |
  +------------------V-------------+                                 |
  |  +---------------V-----------+ |                                 |
  |  |         RFC 2573          | |                                 |
  |  | SNMP-NOTIFICATION-MIB     | |                                 |
  |  +--------+--------------+-+-+ |                                 |
  |           |              | |   |                                 |
  |           |              | +------------------+                  |
  |           |              |     |              |                  |
  |           |              |     |   +----------V--------------+   |
  |           |              |     |   | +--------V---------+    |   |
  | +---------V------------+ |     |   | | Alarm Modelling  |    |   |
  | |       RFC 3014       | |     |   | | (descriptions)   |    |   |
  | | NOTIFICATION-LOG-MIB | |     |   | +--------+---------+    |   |
  | +----------------------+ |     |   |          |              |   |
  |                          |     |   | +--------V------------+ |   |
  | +------------------------V-+   |   | | Generic: Model-     | |   |
  | |         RFC 2573         |   |   | | Active : Specific   | |   |
  | | SNMP-TARGET-MIB          |   |   | | Alarms : Extensions | |   |
  | +----------+---------------+   |   | +--------+------------+ |   |
  |            |                   |   |          |              |   |
  +------------|-------------------+   +----------|--------------+   |
               |                                  |                  |
               |                                  +------------------+
               V
        Informs & Traps

Note that there are really only two changes to the
existing diagram:  (1) swapping the SNMP-TARGET-MIB and
SNMP-NOTIFICATION-MIB labels, which has already been
agreed on this list, and (2) feeding the output of the
SNMP-NOTIFICATION-MIB to alarm processing (just like the
log MIB), rather than having the alarm processing "tap"
the inputs into the SNMP-NOTIFICATION-MIB.

 ------------------------------------------------------
 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: Sun, 28 Apr 2002 21:57:36 -0700

HI,

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

>   administrator can provide different access for different users.

VVVVVVVV
>   same access control rules as described for a Notification

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

>   access control for those tables.
I don't believe that we should repeat the same mistakes found
in other MIB modules. There is work in progress on fixing
RFC 3014.

>The modified diagram would look something like:

Regards,
/david t. perkins