Re: [NGO] access control

[Andy Bierman <[e-mail]>]

David B Harrington wrote:
> 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.
> 

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


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


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