Re: [Netconf] notification access control

[Andy Bierman <andy at netconfcentral.com>]

Randy Presuhn wrote:
> Hi -
>
> > From: "Andy Bierman" <andy at netconfcentral.com>
> > To: "Phil Shafer" <phil at juniper.net>
> > Cc: "NETCONF" <netconf at ietf.org>
> > Sent: Wednesday, June 17, 2009 1:17 PM
> > Subject: Re: [Netconf] notification access control
> ...
> > The all-or-nothing approach actually helps hackers.
> > If there is no filter, then any dropped notification
> > would stick out like a red flag, since it must have
> > contained some sensitive data. (This works just
> > by watching the traffic with wireshark, without
> > actually being able to read any of the packets.)
> > We should want to make it as difficult as possible
> > to discover the access control policy in use on an agent.
>
> I have a couple of problems with this line of reasoning.
>
> (1) hiding the policy is probably not as important as
> protecting the information covered by that policy.
>
> (2) selective removal of elements from the payload
> can still permit semantic leaks.  Consider something
> analogous to a "linkUp" notification.  For a particular
> interface, the payload might be supressed by such a
> policy, but the notification would still be delivered to
> a party that wasn't supposed to know what was going
> on with that interface.  If that was the only interface
> which would meet the subscription's criteria, then
> even surpressing the payload doesn't prevent the
> information leak.

I think Martin is right.
Since the filters will be removed from monitoring data,
an attacker won't really have any way of knowing which
sessions are trying to filter which content.  Therefore,
presence or absence of a notification does not really
mean anything.

What's the problem if the agent leaves out some subtrees
in the payload on <get> or <notification>?  And why
would the ACM policy be different for <get> or <notification>
in NETCONF? (it's all just SSH2 channel data to me :-)

The argument that the manager may not understand the
notification payload is no different than if the
manager did a NETCONF <get/> on the same data, and
a subset was returned.

Obviously, any system that rejected all <get/> requests
with an access-denied error, would not be very usable.
Silently skipping over unauthorized data is needed
to provide a usable management system. What if an
SNMP MIB walk crashed with an access-control error the
first unauthorized node it hit?  Same problem in NETCONF, no?


> Randy


Andy