Re: [Netconf] notification access control

[Andy Bierman <andy at netconfcentral.com>]

Randy Presuhn wrote:
> Hi -
>
> > From: "Andy Bierman" <andy at netconfcentral.com>
> > To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> > Cc: "NETCONF" <netconf at ietf.org>
> > Sent: Wednesday, June 17, 2009 6:47 PM
> > Subject: Re: [Netconf] notification access control
> ...
> > I don't understand.
> > I can't see any data on another SSH session
> > without knowing the keys for that other session.
>
> Again that's not the issue.  Don't think about evesdroppers.
> Don't think about multiple session.  Thnk about what a single
> user is permitted to see on his own, properly authorized session.
>
> > There isn't any "no-auth/no-priv" in NETCONF.
> > The other session could be subscribed to a different
> > stream as well.
>
> That's not the concern.  Think about what it is possible to
> infer from what one sees one one's own even stream under
> this sort of access control policy.
>  
> > You can tell from watching traffic that 2 sessions
> > are getting significantly different sized notifications
> > delivered at the same time.  You don't need to be logged
> > in to the agent to watch another session's traffic and
> > guess that.
>
> Doesn't matter.  Management traffic always has been and
> probably always will be subject to all sorts of flow analysis
> attacks. That doesn't concern me at all.
>
> My concern is how relying on redaction of notification payloads
> could leak information to an *authorized* user.
>
> > > > > How did we get from notifications into get requests?
> > > > To me, a <get> and a <notification> that reveal the
> > > > same information are just 'read' operations.
> > > > I do not understand why access control should work
> > > > differently for these 2 forms of a read operation.
> > > A notification conveys more information than just its
> > > payload.
> > How important is this threat, since all data is probably
> > encrypted in NETCONF?
>
> I'm not concerned about evesdroppers here.  I'm concerned
> about the information leaked to authenticated users.
>
> Simple example:
> ISP has equipment with dedicated interfaces for two
> companies.  Let's call them AndyCorp and RandyCorp.
> Each of these companies is provided (limited) access to
> its dedicated interfaces, and should be kept in the dark
> about what's happening with the competitor's interfaces.
> By subscribing to all notifications, RandyCorp could get
> a pretty good idea what's happening at AndyCorp, even if
> all the AndyCorp content was stripped from the notifications.

I'm not seeing the security hole here.
Why assume that the ACM cannot simply
put a filter on the eventType, which is the
most common usage of a filter?  That way
the entire notification will be dropped.

But that is up to the operator to decide by
configuring the ACM one way or another.
The vendor should use virtual routers or some
solution like that if ACM alone cannot be trusted
to prevent one org from spying on another.


> > What about utility?
> >
> > Back to my example, what if the application has
> > a cache of the <running> config database,
> > and depends on the 'config-change' event
> > to trigger a cache refresh?  It does not
> > care which user changed the config, but
> > missing the event completely (due to operator security policy)
> > will break the application.
>
> No, a config-change for information which that application is not
> permitted to access is pointless.
>
> Randy


Andy