Re: [Netconf] notification access control

["Randy Presuhn" <randy_presuhn at mindspring.com>]

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.

> 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