Subject: [NGO] access control

From: "David B Harrington" <[email-masked]>
Date: Tue, 18 Mar 2008 12:58:43 -0400

Hi,

Mehmet, Andy, and I think access control needs to be discussed
somewhat. Many people in this WG do not have much experience with
access control issues, so let me try to provide a touch of background
why this is important to discuss.

I am going to change terminology a bit. In ISMS we have found that the
SNMP term "access control" conflicts with other definitions of access
control, especially the access to network services provided by AAA
protocols. Really what we need to talk about is authorization, and it
is authorization to have access to something.

RADEXT and ISMS are developing an authorization solution based on
named policies, and the solution will work for SNMP, CLI, Netconf, and
other management protocols. This work will work with RADIUS and
Diameter and can be extended to other AAA protocols. Effectively, it
will provide a way to dynamically determine which authorization policy
should be applied to a user. This should solve part of the problem for
you. 

What the RADEXT/ISMS solution won't do is discuss how to apply the
policy to your protocol and data models. This WG needs to think about
what types of authorization need to be applied. we need to consider
whether authorization to read/write/create configuration information
will be applied at the level of the data elements, or the document, or
the operation, or the class, or something else. It might be possible
to do it multiple ways, but having one standard approach will improve
security and interoperability.

We need to understand how authorization approaches might impact the
way our protocol works, and **especially** the way operators have to
"think about" authorization policies.

In SNMP, using the View-based access control approach, operators need
to think about authorizing read and write access to trees of data
elements. When operators perform a task such as provisioning a
service, all the knobs they need to manipulate are not necesarily in
the same subtree. In addition, an administrator manager might want to
authorize an operator to be able to perform a particular task, but not
other tasks that might happen to touch the same data elements. There
is a mismatch between a task-based "model" and the tree-based data
model in SNMP. This mismatch can make defining authorization policies
NOT very operator-friendly.

If authorization is based on operations, and all operations are
defined as part of the base protocol, this is fairly easy. If new
operations can be added as part of data models, this becomes more
complex. It becomes especially complex if vendors add new data models
in each release, or data models can be added incrementally in a
master-subagent implementation, or if users somehow can add new data
models the administrators don't even know about such as by adding a
new blade to a chassis. And if we don't standardize how
operation-based authorization is going to be done before we start
publishing models with new operations, then the onus will be on the
operators to figure it out. That is NOT operator-friendly.

If authorization is based on XML documents, and those XML documents
represent  full configuration datastores, then we don't have much
granularity. If we can authorize access to parts of an XML document,
then we have to work out how one defines the parts including those
that might be developed as vendor-specific models. Do operators think
about configuration in terms of parts of XML documents? Some probably
do, depending on how they do configuration management.

Does anybody think that defining authorization rules defining a long
list of XPath expressions and evaluating how those rules will
intersect and overlap will be human-friendly? 

As we design a human-friendly modeling language, we need to think
about what will make defining authorization rules for Netconf
human-friendly.

David Harrington
[email-masked]
[email-masked]
[email-masked]

_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Mar 2008 13:36:53 -0700

> why this is important to discuss.

Thanks for clarifying some things.

With NETCONF, the actual XML subtree can be a relevant unit
of data, depending on the DM design.  Using 'entire subtree'
as the appropriate granularity, and a well-constrained Xpath
expression to specify the start of the sub-tree, the same
mechanism can be used to achieve arbitrary granularity.
I think there is some consensus in this approach to
specifying a configuration data subset.  Full Xpath
would be very risky, but not a YANG instance-identifier.

NETCONF has user-defined actions/methods/procedures built-in.
This has to fully considered in the design.  It is not enough
to protect the routing config knobs, but leave the 'reset-entire-chassis'
type of RPC operation unprotected.

There may be DML clauses for authorization to protocol operations
and configuration data needed beyond 'config true/false',
so this topic is relevant now.  Perhaps tagging security-sensitive
data/operations somehow in the DML would help.

One of the many lessons learned from SMING was that vendors
would not tolerate a MIB language that changed -- at all.
It is way too expensive to support multiple DML variants.
A development approach in the IETF that relied on 'adding on'
bits and pieces to the MIB language was soundly rejected.
I think that logic still holds today.  While an an-hoc,
piece at-at-a-time approach may work well for protocol extensions,
it doesn't work well for the MIB language.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Mar 2008 10:11:45 +0100

On Tue, Mar 18, 2008 at 01:36:53PM -0700, Andy Bierman wrote:
 
> I think that logic still holds today.

I do not subscribe to this statement. The extensibility of SMIng has
in fact been carried forward to YANG and as far as I can tell this
will be used at least for vendor extensions.

Andy, why do you not get a team together to work out a decent access
control proposal? This would be forward progress...

/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/>
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Mar 2008 04:38:27 -0700

> will be used at least for vendor extensions.

I don't see how this helps the standard at all.
Vendors can always do whatever they want in their own data models.
Producing incremental versions of the standard is not acceptable.
I'm not concerned at all if vendors want to create their own
proprietary languages.

I doubt vendors will accept a new standard DML every time
the IETF wants to add 'one more clause'.  I think it will be very
difficult to introduce new versions of the DML.

> control proposal? This would be forward progress...

Because I already posted a draft on access control (as did 4 or 5 others)
and they were all ignored, so I'm pretty sure that's what would happen again.

Andy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Wed, 19 Mar 2008 13:13:48 +0100

> control proposal? This would be forward progress...

My understanding at the NETCONF session at IETF71, Andy with Dave Harington
were going to do this, no?

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Mar 2008 13:55:29 +0100

> difficult to introduce new versions of the DML.

Lets simply disagree on this. I believe extensibility of a DML is much
like extensibility of a protocol a good thing.

> Because I already posted a draft on access control (as did 4 or 5
> others) and they were all ignored, so I'm pretty sure that's what
> would happen again.

Do you seriously believe the many complaints you post here are going
to change that? Perhaps it is time to revise / integrate drafts and to
try again. This would be a more constructive approach to make
progress.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Mar 2008 07:59:25 -0700

> like extensibility of a protocol a good thing.

The vendors participating in SMING made it very clear
that supporting multiple versions of the the SMI would
be too expensive to be worth it.

> try again. This would be a more constructive approach to make

I am not trying to work on access control now, just trying
to understand the requirements.

Several people have noted that a development approach for a
data modeling language should consider many (if not all)
aspects of system design.

There will be many opportunities for reviewing and changing
the DML.  I may propose changes to the DML to support access control
configuration and enforcement.

I expect that any and all DML features are on the table for discussion
and access control is not special in that regard.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Mar 2008 17:18:31 +0100

> be too expensive to be worth it.

I don't know what you mean with multiple versions of the SMI. I stick
to my position that extensibility of a DML is much like extensibility
of a protocol a good thing.

/js