Subject: Re: Question Inform Request

From: David Harrington <[email-masked]>
Date: Wed, 01 Dec 1999 10:31:33 -0500

I would choose #1. 

I consider this the best approach for a number of reasons:

- The security credentials at the time the notifications were logged
permitted them to be logged. If the person is no longer trusted, they
probably wouldn't get the continued access to B either, or read access
to the log for that matter. So the fact that the user is still trusted
enough  to have access to B indicates to me that access to A's old
notifications will not be considered problematic.

- The info in the notification is a static report of the state of A when
the notify was sent. Notifications are used to send info that is
normally time-sensitive, and has a limited window of utility. If an
administrator has had time to change the VACM for that user, there is a
fair likelihood that the window of utility has passed. 

Even if the utility window has not been exceeded, and assuming the
administrator wants to prevent the user from doing damage to the
network, if the user isn't allowed access to A's notifications in the
log, then they probably are also not allowed access to A's current (and
forward) configuration, so the info contained in the notification is
probably not helpful if the user cannot subsequently act upon A. 

Of course if the old notifications contain plain-text passwords, or
other sensitive data, then they have larger problems than the notify log
anyway. 

- The Notify-Log document does not suggest doing entry-by-entry access
control for reads from the log, and access control to the whole log. I
think it would be adding tremendous complexity to add entry-by-entry
read access control, especially given the mix of locally- and remotely-
generated notifications.

- The SNMPv3 WG found fate-sharing of tables to be unnecessarily
complex.
Here, we would be fate-sharing across MIB modules. Given AgentX, these
may be implemented in different sub-agents. When the VACM is changed,
how would the Notify-Log implementation know? Will VACM be changed to
send a notify to the notify-log implementation, or should the Notify-Log
implementation constantly check the VACM tables for changes?

- Setting a discontinuity object and clearing the table could open a
security hole for an attacker to erase the log of history which contains
information that would pinpoint the attacker and/or the attacks.

my $.02

dbh

Ramanathan Kavasseri wrote:
> 
> At 08:56 AM 11/30/99 -0500, David Harrington wrote:
> >
> >I suggest the opportunity for another mib module that provides a place
> >to record filter conditions for notify-log. Maybe DISMAN WG will choose
> >to merge the two into one document, but it could also remain as two.
> 
> That's Yet-Another-Filtering-MIB :-(
> I'd argue for a common infrastructure for filtering, instead of having applications each with their own filtering mechanisms.
> 
> Talking about filtering, someone implementing the Notification-Logmib rasied
> the following issues to me:
> 
> User Foo has a named notification log called "Foolog", which contains
> instances of notifications "A" and "B". After several notifications are logged,
> Foo's notify view changes - now, notif "A" is still included, but notif "B"
> is excluded. What should the log do? Should it:
> 1. leave the existing log entries as is, but log only notif A going forward?
> 2. remove old notification entries which were i the log but are now excluded
> by the view?
> 3. leave the notif entries in the log, but filter each get PDU according to the
> notify-view of the user/comm string used in the get query for the log?
> 4. set a discontinuity object (which is not in the notif-log MIB today),
> clear out the existing log, and log new entries?
> 5. In a discontinuityTable, set a discontinuity object, and the log entry from which the new view or filter entry took effect.
> 
> I'm not sure what the preferred/desired behaviour should be...
> My preference is in the following order (best to worst):
> 5, 1, 4
> However, I'm not sure if this issue came up in the past, or if
> there are better ways to solve it.
> 
> Ram
> 
> >I suggest that such a filtering mib might constrain according to
> >credentials, or might explicitly list authorized notify senders. It also
> >maight take advantage of the expression mib for forming conditions.
> >
> >dbh
> >
> >Randy Presuhn wrote:
> >>
> >> Hi -
> >>
> >> > To: Randy Presuhn <[email-masked]>
> >> > Cc: [email-masked], [email-masked]
> >> > Subject: Re: Question Inform Request
> >> > References: <[email-masked]>
> >> > From: Wes Hardaker <[email-masked]>
> >> > Date: 29 Nov 1999 16:15:23 -0800
> >> ...
> >> > Randy> I think nlmConfigLogFilterName from
> >> > Randy> <draft-ietf-disman-notif-log-mib-12.txt> takes care of this
> >> > Randy> scenario by permitting the creation of appropriately selective
> >> > Randy> logs.
> >> >
> >> > Yes, but you can't configure it to say "only log authenticated
> >> > requests for this log" which means I can flood a CR with messages to
> >> > over-write the history limit or over-run the processes memory...
> >> >
> >> > Randy> The decision by the logging application to omit information
> >> > Randy> delivered to that application is NOT an access control
> >> > Randy> function.  Rather, it's part of the normal operation of such a
> >> > Randy> logging application.
> >> >
> >> > Ok, I understand you're view point.  I still disagree simply because I
> >> > think it would benefit from standardization, but I won't argue for it
> >> > any longer (unless other people agree start to agree with me).
> >> ...
> >>
> >> And I think I understand yours, and actually agree with (some of)
> >> what you're advocating.  I think the difference is whether the
> >> ability to limit what gets logged based on the sender's credentials
> >> should be part of the SNMP application infrastructure or the logging
> >> application itself.
> >>
> >> I think the current documents tacitly assume that such a decision
> >> would be application specific, and, if we wanted to be able to
> >> protect the notification log from such an attack, we'd need to modify
> >> <draft-ietf-disman-notif-log-mib-12.txt> to include the ability to
> >> limit what gets logged based on senders' credentials.  The other way
> >> of looking at the problem, the perspective I think you're taking, is
> >> to approach this problem as being generic to all notification receiver
> >> applications, and thus something to be handled in conjunction with the
> >> other MIBs from RFC 2573.
> >>
> >> The more standardized notification receiver applications we have, the
> >> stronger the argument for using common infrastructure for this. However,
> >> we also need to consider whether the policy (which (authenticated)
> >> notification sources should actually be logged) belongs to the security
> >> administrator or to the log applications' respective users.
> >>
> >>  -------------------------N-E-W---A-D-D-R-E-S-S--------------------------
> >>  Randy Presuhn           [email-masked]       http://www.bmc.com/
> >>  Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
> >>  Fax:   +1 408 965-0359  San Jose, California 95131  USA
> >>  ------------------------------------------------------------------------
> >>  Any relationship between my opinions and BMC's should be coincidental.
> >>  ------------------------------------------------------------------------
> >