Subject: RE: architecture and security

From: "Kent Watsen" <[email-masked]>
Date: Thu, 6 Apr 2006 20:45:24 -0700

Andy wrote:
> So the agent has to check the filters to see if they can ever
> match a data model that the subscriber is not allowed to see,
> and reject the subscription request with an access-denied error.
>
> Or does the agent silently omit notifications which don't resolve
> to access-granted for that receiver?

Actually, both statements are true: 

1. When the subscription-request comes in, the system must authenticate
that the request only subscribes to events the client is authorized to
receive

2. However, when each notification is generated by the system, the
system only forwards it to the client if it already has a subscription
in place for that kind of event

In case you think that I'm contradicting my earlier statement
"eliminates the system from having to apply filters to the responses",
what I meant to say is that it eliminates *access control* from having
to apply filters to the responses.  This is true since any notification
matching the subscription request, which was authorized, is also
implicitly authorized to be sent to the client

Kent

--
Kent Watsen
NSM Architect
Juniper Networks

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Apr 2006 00:17:24 -0700

> implicitly authorized to be sent to the client

I don't think it is so simple.
Not all data on the agent is static.
There could be data that is not instantiated at
the time of the subscription request that the manager
is not allowed to see.  Therefore, the agent has to
check access control for each notification sent.

This assumes there is finer grained access control
than "all config events" or "all faults".  That would
not really be good enough to protect sensitive data.

> Kent

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Apr 2006 11:08:44 -0700

Hi -

> From: "Kent Watsen" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: "Netconf (E-mail)" <[email-masked]>
> Sent: Thursday, April 06, 2006 8:45 PM
> Subject: RE: architecture and security
...
> implicitly authorized to be sent to the client
...

It sounds like these access control policies are only in terms
of the event type, and not in terms of the specific resources
being managed.  In other words, if Customer A should only
be able to access interface (a) configuration data,
and Customer B should only be able to access interface (b),
and the same event type is defined for both interfaces,
we'd have a problem.

Or is this simply one of those things netconf won't support?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Apr 2006 12:03:54 -0700

Hi -
 
> From: "David T. Perkins" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Sent: Monday, April 10, 2006 11:34 AM
> Subject: Re: architecture and security
... 
> Given the desire "to make part of management information
> such as that for a single interface available to users
> of that part and not to other users", SNMPv3 attempts
> to do this via setting up VACM authorization rules.
> The result is an inconsistent set of management info.
...

How so?

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 10 Apr 2006 12:19:37 -0700 (PDT)

HI,

Consider ifNumber. If a device has, say, 4 interfaces,
but only a single one allows access to management info,
then it appears that the management info is incorrect,
since ifNumber will be 4 but only one interface is
in the table.
If you go through all MIB modules and try to set up
VACM so that a limited set of info is available, then
you will most likely end up with a set of management
info that is accessible that appears is coming
from a broken SNMP agent. 

You have to go through each on a case by case bases.

> > The result is an inconsistent set of management info.
Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Apr 2006 21:52:39 +0200

> > The result is an inconsistent set of management info.

I tend to agree with Dave Perkins.

I have recently looked at a different problem, namely the
anonymization (or pseudonymization) of management traffic and
configurations and it is virtually impossible to get this right since
information leaks through very easily (just consider an IPv6 address
derived from an IEEE MAC address which is then used to derive an
SnmpEngineID - and now your task is to anonymize the MAC address).
While it might be possible to get things right for a given device with
enough man-power for standard read-only tables (and I very much doubt
that someone is willing spending this money for a single device while
the next device means you have to repeat major parts of the exercise
due to many private MIB objects), things melt down quite quickly once
you face tables where users can name entries or even put descriptions
or other opaque things into an agent. Operationally useful names
usually carry quite a bit of context (this is exactly why they are
useful to operators) and so it is very likely that information leaks
through these descriptions.

Talking about VACM: VACM fails by design when it comes to situations
where the item you want to base your access control decision is not in
the OID.  No, I am not asking for a VACM++ - this would only help in
theory and make things worse in practice.

I believe that in practice, we need the implementations to help us do
the right thing for a given set of well understood and defined
profiles. Dave's idea to provide views by means of virtualized devices
surely sounds interesting, although probably too far reaching for IETF
work.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 10 Apr 2006 11:34:45 -0700 (PDT)

HI,

This goes back to modeling vs authorization.

Given the desire "to make part of management information
such as that for a single interface available to users
of that part and not to other users", SNMPv3 attempts
to do this via setting up VACM authorization rules.
The result is an inconsistent set of management info.
Another approach is to create a virtual device
that appears as simple and implements only the
functions that a user is authorized to access
management info. And finally, the management info
can be collected from the device and made available
in another format (and data model).

I see the authorization approach as a temporary
quick fix that sort of works in limited cases.

Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Apr 2006 13:31:59 -0700

Hi -

> Sent: Monday, April 10, 2006 12:19 PM
...
> since ifNumber will be 4 but only one interface is

No, it means only one interface could be accessed.
Since my ATM card allows me to access only three
accounts, would it be reasonable to conclude that my
bank only has three customer accounts?  Of course not.
We should not see inconsistancy where there are merely
unwarranted inferences.

...

More likely, an application that is making inferences that
are not justified.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Apr 2006 13:39:56 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> Sent: Monday, April 10, 2006 12:52 PM
... 
> through these descriptions.

No disagreement on this point, but I think it is quite a different one from
the claim that VACM causes management information to become
inconsistent.

...

Again, no disagreement.  I think the issue for netconf is just what is
needed to do access control on a subscription, and whether the
possibility of changes to configuration or access control policy may
render inadequate a strategy of evaluating the access decision function
only at the time the subscription is created.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Apr 2006 23:00:32 +0200

> the claim that VACM causes management information to become

Executive summary or my elaboration above:

    VACM rules either leak information (because it is too hard or even
    impossible to get them right) or they lead to inconsistencies
    (because they suppress information that should be available).

I do not agree that it is the manager's fault if it assumes certain
information to be available. Sure, a manager should detect cases where
information is missing and not go crazy. But then again, once you have
insufficient information, there is not much useful management one can
expect to happen.

I agree with you so far as that "inconsistent" might be the wrong term
- the term "incomplete" might better describe the situation.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Apr 2006 16:03:59 -0700

Hi -

> Sent: Monday, April 10, 2006 2:00 PM
...
...

Violent agreement.

Randy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 13 Apr 2006 15:21:18 +0200

>> implicitly authorized to be sent to the client

Does this mean that access rights are only checked at subscription ?
What happens if the user successfully subscribes to all notifications
then later his access rights are restricted.
Shall we check at the change of access rights
whether his subscription is still OK and remove it if no ?
Otherwise his rights might be removed and he still receives notifications
as long as he himself does not change his subscription. This latter
case is I feel not satisfactory.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 13 Apr 2006 15:19:41 +0200

I feel this is a feature not a bug.
If you have fine grained access control
you must be prepared that you might not see all interfaces. The first number
you get is the number of all interfaces not the number of interfaces visible to user A.
Can you give another example ?

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 13 Apr 2006 15:22:17 +0200

Defining access control on a resource level is a
requirement for Ericsson. This still has two cases:
1) Managed Object type or class based: User A has access
to interfaces but not to routing information, while
user B can only access routing but not interfaces
2) Managed Object instance based: User A can access
IF=eth0 but not IF=eth1 while User B can access
IF=eth1 but not IF=eth0.

Both cases are required for us. Netconf should at
least not make it impossible to implement this.
Balazs

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 13 Apr 2006 08:12:00 -0700 (PDT)

HI,

Can you describe the problem that you are trying to
solve (instead of TELLing us THE solution). And have
you looked at other solutions, and if so, would
you describe the pros and cons of each.

Regards,
/david t. perkins

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Apr 2006 09:27:33 -0700

> you describe the pros and cons of each.

I think both examples below make sense.

Access by feature classification regardless of XML subtree
location is useful.  This can also be done by locating
related features under a common parent node, but often NE features
have some config data spread out all over the XML tree.
(Some global, per-interface, per-circuit, etc.)

I don't think 'interfaces' is granular enough, or an appropriate feature
category.

A config might look like:

<acme>
   <feature-A> ...
   <feature-B> ...
   <interfaces>
      <interface>
         <name>eth0</name>
         <feature-A> ...
         <feature-C> ...
      </interface>
   </interface>
</acme>

Access to all 'interfaces' in this model doesn't make much sense.
Access to all of 'feature-A' regardless of where the XML is located
makes sense.  Common namespace usage makes this easy.

I also want to point out that nobody is asking for instance granularity
within a row.  People have asked for "user A can look at all instances
of the foo object" or "user B can look at all the data in row X of
the interfaces table".  This is very different than VACM (and much
simpler/better IMO), where the columns in an individual row can have
different access control rights for every user.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Apr 2006 20:21:52 +0200

> different access control rights for every user.

Still, the hard problem are references to things under access control.
Some boxes to maintain fault history tables that may refer to
interfaces (or to physical ports that are related to interfaces). How
will the access control model deal with such cases?

Of course, fault history data is not config data so you can take the
formal position that this example is out of scope for netconf access
control. But I think the question of how to deal with references will
remain and this is especially nasty if references are embedded into
identifiers.

Note that I am not asking for a complex solution - I just believe we
should be very clear what an access control model can do and what not.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Apr 2006 12:16:14 -0700

> remain and this is especially nasty if references are embedded into

References in identifiers -- you mean like information
carried in the instance portion of an OID?

Not sure what you mean

> should be very clear what an access control model can do and what not.

Agreed.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Apr 2006 21:26:08 +0200

> carried in the instance portion of an OID?

Operators seem to like to name things in meaningful ways and these
names frequently carry information which may be sensitive. If you want
to define views so that different people can look at a box, you have
to ensure that nothing leaks through which might be embedded in
operator assigned names (and thus can't be really handled by access
control rules unless you have embedded AI).

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 14 Apr 2006 11:14:40 +0200

I have to say that my requirements (coming from telecom operators) do ask for some 
complicated cases.

I need to handle the following two cases:
1) A router with multiple virtual routers. Each virtual router might be managed by a 
separate organization. This would mean that a subtree of the data model must be assigned 
to each organization.
2) I have a big box: where user A is responsible for configuration management while user B 
is responsible for performance management. I want to keep them separate. This would mean 
that some type of objects (representing performance measurements) should be handled 
separately.

Information leaks can't be fully avoided but with careful modeling of data and 
documentation warning about the possibility of some leaks we can provide a solution that 
is better then just saying NO.

All I am asking for that Netconf should not actively prohibit such a solution.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Apr 2006 08:20:39 -0700

Balazs Lengyel wrote:
> I have to say that my requirements (coming from telecom operators) do 
> ask for some complicated cases.
> 
> 1) A router with multiple virtual routers. Each virtual router might be 
> managed by a separate organization. This would mean that a subtree of 
> the data model must be assigned to each organization.
> 2) I have a big box: where user A is responsible for configuration 
> management while user B is responsible for performance management. I 
> want to keep them separate. This would mean that some type of objects 
> (representing performance measurements) should be handled separately.
> 

You can embed classification in the schema, or in the
XML tree itself, in elements or attributes.
You can use namespaces.  Access control in XML
shouldn't be that hard.

> Information leaks can't be fully avoided but with careful modeling of 
> data and documentation warning about the possibility of some leaks we 
> can provide a solution that is better then just saying NO.
> 

We are not likely to solve the rmonAlarmVariable (object shadowing)
problem with netconf access control.  Since naming and data components
are treated the same in XML (unlike SMI OIDs) there is no need
to worry about the name of an instance leaking information,
but history buffers, variable-pointers, data embedded in
show command printfs, can all leak information.  We aren't
going to rid the world of these dangers.
Security considerations sections are there to be read
(no, really, it's not all boilerplate! ;-)

I don't understand Juergen's comment about meaningful names.
Info like ifAlias or ifName is 'just more data' and
covered by access control the same as other objects.

> All I am asking for that Netconf should not actively prohibit such a 

What specific items in the murky solution space prohibit
which specific items in your problem space?  I don't see why
you couldn't come up with an access control model that works.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 14 Apr 2006 11:46:29 -0400

Balazs Lengyel writes:
>1) A router with multiple virtual routers.
>2) I have a big box: where user A is responsible for ...

One of the core concepts behind netconf was leveraging the existing
CLI concepts, infrastructure and implemenation to avoid being a
third management model (after the CLI and SNMP).  By avoiding this,
we hope to make netconf easier to implement, more powerful to use,
and more familiar to operators.

This was the motivation behind mirroring the existing configuration
models implemented by vendors (running, distinct-startup, candidate)
rather than rolling our own.  (It also helped us avoid the tendency
to invent new "must-have" features that no one ever heard of ;^)

So when I think of issues like classes of users and virtual routers,
the first question that comes to mind is how do existing routers
handle this?  Virtual routers are typically keyed off either incoming
interface or user login name.  The router knows which VR you are
accessing before you start entering commands.  This same solution
can be leveraged for netconf.  In the same way that a CLI user should
only see local log files or messages for their own VR, so a netconf
login should only have access to the notifications for the VR into
which the netconf session is attached.

Similar for classes of users.  If the CLI filters syslog files/messages
by user class, this same mechanism should be leveraged for netconf.  If
you couldn't see if as a user, you should see if as a netconf session.

So netconf should definitely not prevent you from doing the things
you want.  It should help you expose your device's abilities while
leveraging the existing infrastructure.

Thanks,
 Phil