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 5:30 PM
> > Subject: Re: [Netconf] notification access control
> >
> > 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 4:30 PM
> > > > Subject: Re: [Netconf] notification access control
> > > >
> > > > 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
> > > ...
> > > > 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.
> > > You're only looking at the potential eavesdropper.
> > > Consider where the atacker is the authorized user,
> > > trying to ferrer out information s/he is not supposed
> > > to be able to have access to.
> > How does guessing that one session received a
> > notification but another one didn't help here?
>
> That's not the issue.  Don't think about eavesdroppers.
> Think about an authorized user being able to figure
> out things from the information stream legitimately
> delivered with "redacted" payloads.  Trivial example:
> system has two users who are not allowed to see each
> others' data.  By subscribing to all events, the receipt
> of ones with empty or partial payloads would let one
> user know what was going on with the other.

I don't understand.
I can't see any data on another SSH session
without knowing the keys for that other session.
There isn't any "no-auth/no-priv" in NETCONF.
The other session could be subscribed to a different
stream as well.

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.


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

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.


> Randy

Andy