[NGO] access control

["David B Harrington" <[e-mail]>]

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
[e-mail]
[e-mail]
[e-mail]



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