Subject: Re: Question Inform Request

From: Randy Presuhn <[email-masked]>
Date: Mon, 29 Nov 1999 15:28:53 -0800 (PST)

Hi -

> To: "Harrington, David" <[email-masked]>
> Cc: "'Wes Hardaker'" <[email-masked]>, [email-masked]
> Subject: Re: Question Inform Request
> References: <[email-masked]>
> From: Wes Hardaker <[email-masked]>
> Date: 29 Nov 1999 11:24:35 -0800
...
> Harrington> I think the docs do not say that the receiver is not
> Harrington> allowed check the VACM datastore for the authorized access
> Harrington> to the data of received notifications.
> ...
> Harrington> I think it would be inappropriate for the application
> Harrington> behavior to be dictated by the protocol.
> 
> Thats where we disagree.  I agree that it shouldn't be mandatory (as
> nothing is truly mandatory, as long as you get the bytes on the wire
> right), but I do think it should be mentioned in there at a minimum
> that "If you want or need to check for access control rights for the
> incoming PDU, you should consider doing it at this point before you
> take any action based upon it.  An example of doing this would
> include, but is not limited to, applying step #3 from section 3.3
> above."

VACM exists to prevent unauthorized disclosure / modification of
information.  It doesn't make sense to me to apply access control to
incoming notifications.  The information has already been disclosed;
the sender is satisfied that the recipient has adequate credentials.
Now if the recipient wants to decide "I shouldn't have seen that message
I just read", I guess it can cover its eyes and try to forget what it
saw, but I can't imagine the security folks taking much comfort in it.

> For instance, if its not implemented in a way that checks access
> control then I can quite easily flush out the contents of the disman
> notif-log mib to hide notifications that have been generated
> indicating something bad that I've done.  
...

I think nlmConfigLogFilterName from
<draft-ietf-disman-notif-log-mib-12.txt>
takes care of this scenario by permitting
the creation of appropriately selective logs.

The decision by the logging application to omit information delivered
to that application is NOT an access control function.  Rather, it's
part of the normal operation of such a logging application.

Whether anyone is in turn permitted to see what has been logged IS a
security policy matter.

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

---

From: Wes Hardaker <[email-masked]>
Date: 29 Nov 1999 16:15:23 -0800

>>>>> On Mon, 29 Nov 1999 15:28:53 -0800 (PST), Randy Presuhn <[email-masked]> said:

Randy> VACM exists to prevent unauthorized disclosure / modification
Randy> of information.  It doesn't make sense to me to apply access
Randy> control to incoming notifications.  The information has already
Randy> been disclosed; the sender is satisfied that the recipient has
Randy> adequate credentials.

True.  If thats all that the access control model is meant to do, then
I guess you're right.  My only point was that the more complex ==
better CRs out there perform tasks based on an incoming notification
(99% of the time paging someone or setting an icon color, etc).

Wes> For instance, if its not implemented in a way that checks access
Wes> control then I can quite easily flush out the contents of the disman
Wes> notif-log mib to hide notifications that have been generated
Wes> indicating something bad that I've done.  

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

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis