Subject: [Netconf] notification access control

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 12:25:43 -0700

Hi,

I know I keep complaining about the lack of a coherent
ACM in NETCONF, but the presumption of a completely
unspecified access control in this RFC is problematic.

3.2, para 4:

    After generation of the <notification> element, access control is
    applied by the server.  If a session does not have permission to
    receive the <notification>, then it is discarded for that session,
    and processing of the internal event is completed for that session.

Without any actual ACM, what does 'permission' really mean?

Why is there a presumption that data delivered to a session
via <get> should have a different ACM architecture than data
delivered to the exact same session via <notification>?

The RFC never says the agent MUST make an all-or-nothing
decision wrt/ granting permission to deliver the notification.
What if access control is enforced at a lower level,
in the XML generation, so no matter what RPC method is
trying to access /path/to/secret-password, they can't?

I will assume an implementation may silently prune
parts of the payload from the notification, due to access
control policy.  The notification MUST be dropped
if the <eventType> element would be filtered out,
in violation of the <notification> element schema.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 17 Jun 2009 15:44:11 -0400

>in violation of the <notification> element schema.

Yes, let's add this as an issue list for a future -bis, since an
implementation should be able to prune inappropriate elements from
the notification.

Also we should repair the word "after" in the above text, since
there isn't any explicit to generate the <notification> element at
all if no one is permitted to receive the content.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 13:17:53 -0700

> all if no one is permitted to receive the content.

yes -- I assume you mean the 'stream n' delivery in figure 2.
The replay (logging service) is given a copy of the event.
Delivery of replay notifications to a stream is no different
than live events.  (not shown in figure 2.)

Also, the 'filter' step in figure 2 is misleading.
ACM and filtering is not applied on the stream, but
independently, on each subscription (not shown).

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.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Jun 2009 22:33:46 +0200 (CEST)

> actually being able to read any of the packets.)

How would a hacker know that a notification was *not* sent by watching
the traffic?

I don't care that much if the entire notif is dropped, or some element
is pruned, but the current spec is pretty clear - the notification
MUST be dropped.  So a 5277 compliant server cannot prune
elements from the notifications.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 13:57:36 -0700

> How would a hacker know that a notification was *not* sent by watching

by watching traffic patterns (when multiple subscriptions
are active).

> elements from the notifications.

I don't think the RFC says that anywhere.
There is just the vague text about granting
permission.  IMO, that meant that the manager
has permission to see the <eventType> element,
but it does not mean the entire payload is going
to be delivered, if ACM policy decides otherwise.

What if the ACM rule is simply:  deny "//secret-stuff".
What if the ACM defines 'deny on read access' to mean prune?
(And what about applying access control to 'anyxml'
nodes, like a subtree <filter>?)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Jun 2009 23:10:05 +0200 (CEST)

> by watching traffic patterns (when multiple subscriptions

But you wouldn't know that the different subscriptions use the same
filter.

> to be delivered, if ACM policy decides otherwise.

Ok, I agree the text is vague.  But maybe this is good - it means that
the ACM can define the behavior without a 5277bis.

(Compare with 4741, it doesn't say what the result is if you do a
<get> w/o a filter when you don't have read access to everything - do
you get all data you're allowed to see (yes), or do you get an
access-denied error (no)?)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 14:21:09 -0700

> But you wouldn't know that the different subscriptions use the same

true -- especially since the filter element is
getting removed from the ietf-netconf-state module.

> access-denied error (no)?)

For write access and exec access (invoke RPC method),
an access-denied error is generated.  For all read operations,
the data is just silently dropped.

Since there is no standard ACM, and assumptions are valid,
including these.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Jun 2009 15:39:43 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: "NETCONF" <[email-masked]>
> Sent: Wednesday, June 17, 2009 1:17 PM
> Subject: Re: [Netconf] notification access control
...
> 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.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 16:30:24 -0700

> even surpressing the payload doesn't prevent the

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?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Jun 2009 01:38:55 +0200

> to discover the access control policy in use on an agent.

I hope SSH makes it difficult enough to do this kind of attack; an
attacker would need a valid session key to make any sense out of the
encrypted byte stream. And if the attacker is able to obtain a valid
session key, well then you likely have a bigger problem.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 16:41:00 -0700

> Hi -

Here is a use-case example of what I mean.

Let's say a WG or vendor defines a config-change
notification that includes a 'username' field
(i.e., who made the config change).

Let's say an operator using equipment purchased
from the vendor decides to implement a security policy
that usernames are restricted data (because they aid
brute-force login attacks which guess usernames).

Should NETCONF be flexible enough to allow the operator
to decide security policy, not the WG or equipment vendor?

IMO, yes.  IMO, SNMP made a big assumption by deciding
that any access-control filtering applied on the payload means
the payload will be unusable by the manager.  NETCONF should
not make the same mistake.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 16:50:15 -0700

> session key, well then you likely have a bigger problem.

Not entirely.
If ClientAliveInterval or ServerAliveInterval is enabled
in openssh, then there will be periodic data sent on
the channel to keep proxies from timing out, etc.
(Plain Keepalive messages are TCP, not SSH.)

These can be guessed (and removed from the data set)
just because they will be the same SSH message at
regular intervals.

Any <rpc-reply> will be immediately preceded by the <rpc>
PDU going the other way, so that is easy to remove
from the data-set.

So, you can easily tell that a session is getting
a notification (or not), but you cannot guess the content.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 17:02:09 -0700

...
> a notification (or not), but you cannot guess the content.

I want to summarize that this is not any new security hole,
and pruning payload data or dropping the notification (on one session
but not another), offers an attacker the same opportunity
to identity 'packets of interest' within the capture log.
Without knowing all the filters as well, this is much
less likely to be a real vulnerability.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Jun 2009 02:10:56 +0200

On Thu, Jun 18, 2009 at 01:50:15AM +0200, Andy Bierman wrote:

[...]
 
> So, you can easily tell that a session is getting a notification (or
> not), but you cannot guess the content.

So what? (And I would be curious to see a demonstration of this
technique at the next IETF. ;-)

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Jun 2009 17:23:09 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Sent: Wednesday, June 17, 2009 4:30 PM
...
> presence or absence of a notification does not really

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.

> in NETCONF? (it's all just SSH2 channel data to me :-)

It's not the omission per se that bothers me.  It's that the
very existence of the notification reveals information.
That's why SNMP doesn't just consider the varbinds
in deciding whether to forward a notification.  Now maybe
this is covered by Netconf's access control framework,
or maybe it isn't.

> manager did a NETCONF <get/> on the same data, and

I don't think anyone is making that argument.

> first unauthorized node it hit?  Same problem in NETCONF, no?

How did we get from notifications into get requests?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 17:30:38 -0700

> to be able to have access to.

How does guessing that one session received a
notification but another one didn't help here?

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

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Jun 2009 18:03:40 -0700

Hi -

> Sent: Wednesday, June 17, 2009 5:30 PM

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.

...
> differently for these 2 forms of a read operation.

A notification conveys more information than just its
payload.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 18:47:05 -0700

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

> A notification conveys more information than just its

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.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Jun 2009 19:48:56 -0700

Hi -

> Sent: Wednesday, June 17, 2009 6:47 PM
...
> 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.

> The other session could be subscribed to a different

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.
 
> in to the agent to watch another session's traffic and

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 important is this threat, since all data is probably

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.

> will break the application.

No, a config-change for information which that application is not
permitted to access is pointless.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Jun 2009 20:01:13 -0700

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

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Jun 2009 20:55:25 -0700

Hi -

> Sent: Wednesday, June 17, 2009 8:01 PM
...
> the entire notification will be dropped.

Because both AndyCorp and RandyCorp will need to get
the same event types.  Consider a linkDown as an example.

> to prevent one org from spying on another.

What I'm saying is that attempts to redact notification payloads
will still leak information since you can't reasonably expect
to limit who should get a notification based on notification type alone.

Randy

---

From: WashamFan <[email-masked]>
Date: Thu, 18 Jun 2009 15:36:10 +0800

Hi,

----- Original Message -----
From: Andy Bierman <[email-masked]>
Date: Thursday, June 18, 2009 3:25 am
Subject: [Netconf] notification access control
To: NETCONF <[email-masked]>

>  Without any actual ACM, what does 'permission' really mean?

I assume read-access.
 
>  delivered to the exact same session via <notification>?

I am not quite sure how data to get differentiate from notif data.
(Since Randy argue that notif data means more than the info
it contains). If yes, notif data should be dropped completely
just as current text says.
  
>  trying to access /path/to/secret-password, they can't?

Although NETCONF ACM is lack, but IMO, the ACM should be
applied on XML data. (I.e., after XML generation). Sorry,
maybe I am misunderstood.

>  in violation of the <notification> element schema.

So, if we treat the notif data as the same way as data to get,
then 3 filters might exist: vendor-defined filter for stream definition,
access control filter and user-defined filter when subscription
is created. the latter two filters should be applied to the XML
data (i.e., after <notification> element generation).

[By the way, I am not sure what <eventType> is refering to?
event stream?]

washam

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 05:00:31 -0700

> the same event types.  Consider a linkDown as an example.

Why assume the ACM is incapable of providing this
data isolation, if that is what the operator wants?
Why assume a <get> operation on the other companies <interface>
entry can be properly protected by the ACM, but not a
<link-down> notification?

> to limit who should get a notification based on notification type alone.

Depending on the environment, the operator can configure
the ACM to do the right thing.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 18 Jun 2009 10:00:15 -0700

Hi -

> Sent: Thursday, June 18, 2009 5:00 AM
...
> the ACM to do the right thing.

The point is this: configuring the ACM to "do the right thing"
would mean that notification payload redaction would not
happen, because the cases where redaction would occur
should have been precluded by access control to begin with.
Or is the idea that payload redaction would function
as a kind of "harm reduction" in cases where the security
administrator didn't set up notification access control correctly?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 10:11:30 -0700

> administrator didn't set up notification access control correctly?

I don't agree with you that all-or-nothing is always the
best choice for delivering notifications.  It is up to the
operator to decide which data is sensitive.

The scenario you are describing is not well-suited to a
single monolithic agent at all.  Instead, each customer
should get their own virtual agent, and use some
sort of proprietary 'glue code' to let each virtual agent have
access to a subset of the real agent.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 18 Jun 2009 10:41:49 -0700

Hi -

> Sent: Thursday, June 18, 2009 10:11 AM
...
> single monolithic agent at all.

I do have a strong bias against monolithic agents.

I think they spell software configuration management
disaster for complex or multi-vendor systems.  But
the current IETF direction seems to be to not worry about
those cases, and let them define their own solutions
as the need arises.  I don't think that was a good choice,
but this is not the place to re-hash old debates.

>  Instead, each customer

"And then a miracle occurs."  :-)

We have clearly different visions of how to make this stuff
work, so I guess I'll just have to wait until we see how that
glue code actually works.  But I am concerned that these
decisions will inexorably paint the developers of the netconf
ACM (or, more likely, ACMs) into a corner.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 10:53:44 -0700

> ACM (or, more likely, ACMs) into a corner.

This is already being done with CLI, so I imagine
someday a NETCONF version might show up.

The problem with ACMs is that they are always too hard
to configure, so they don't get used. That's why I am
experimenting with 'schema content tagging'.
That way, with zero-config, the defaults do the right thing.
(e.g., tag the password leaf as 'very-secure' in the YANG file
with an extension, and the agent knows not to let it be
accessed at all by default (no ACL found)).

Andy