Re: Proposed Update to Netconf Charter

[Andy Bierman <ietf@andybierman.com>]

David B Harrington wrote:

> Hi Andy,
>
>  
>
> > Access control is also critical to get in place early on.
> > I prefer to start simple and evolve the complexity over time.
> > IMO, a mapping to ISMS should be a separate work effort,
> > and probably in that WG.
> >
> > NETCONF AC is unique because it is both "RPC method" and 
> > document oriented.
> > IMO, old approaches like VACM will be clumsy and/or bloated if
> >    
> applied
>  
>
> > to NETCONF.  Some new innovation is required  here.
> >
> >    
>
> I'm interested in your views about the uniqueness of netconf AC. 
>
> In SNMPv3, as you know, we found that all operations could be
> abstracted into read/write/notify types of operations for purposes of
> AC. There was not a real need to distinguish between GET, GETBULK, and
> other proposed GET-XXXX operations. Do you see a real need to
> distinguish between the various <get-xxx> RPC methods, etc., that
> would be initiated by an operator? 
>
> In the SNMPv3 isAccessAllowed() ASI, variableName names the instance
> of the managed object. Would netconf use a similar (XML-based)
> variablename to identify the instance of the managed object? 
>
> Do you expect that "documents" will be aggregations of objects that
> are not necessarily from the same XML subtree? I can see this if the
> document is an HTML web page; but if it is built from data elements
> defined as an XML instance, then would AC based on the underlying XML
> suffice? Cf: a varbind list with an aggregation of various managed
> objects. Do you have something different in mind for documents?
>
> In SNMPv3, we have contexts to differentiate MIB instances. I assume
> such a concept would also be needed for netconf. Do you agree? Is
> "running" and "candidate" about as deep as you need to go for netconf
> contexts, or do you need the greater depth found in the SNMP contexts?
> Do you anticipate a future need to be able to configure, for example,
> the XML instance for a specific blade in a server?
>
> I'm interested in your thoughts on this because VACM has not gained
> very wide acceptance, and a simpler AC model that could be used with
> both netconf's XML hierarchical naming scheme and SNMP's OID
> hierarchical naming scheme (or an XML-based SNMP naming scheme) could
> help both protocols. I'm also interested in probing how the
> requirements for netconf AC and SNMP AC might differ, since this could
> also have an impact on whether ISMS design should even try to be
> future-compatible with netconf. 
>  

Since you asked...

IMO, we need a simple 2-tier access control model
that is independent of higher layer abstractions.


1) access is by group-name, and a group contains a list of user names.
  A user can be included in any number of groups.

2) tier 1 is RPC method access, which is defined by the tuple:
     { namespace-uri, method-name }
  and access is granted by configuring via the tuple
     { namespace-uri, method-name, group-list }

  Example 1: access to the groups 'staff' and 'root' are granted for
  the edit-config method via the following configlet:

  <rpc-access>
    <namespace-uri>urn:ietf:params:xml:ns:netconf:base:1.0</namespace-uri>
    <method-name>edit-config</method-name>
    <group-list>root, staff</group-list>
  </rpc-access>

  Example 2: access to everybody given to 'my-own-method':
 
  <rpc-access>
    <namespace-uri>http://example.net/me/my-own/1.0</namespace-uri>
    <method-name>my-own-method</method-name>
    <group-list>all</group-list>
  </rpc-access>

3) tier 2 is data model access, and defined by the tuple:

 { operation-list, data-namespace, data-path, group-list }

where:

 operation-list is zero or more of the following strings:
    { notify, read, create, merge, replace, delete }
    [Shorthand: the term 'write' == create, merge, replace, delete]
 data-namespace is the URI identifying the data model namespace
 data-path is an absolute XPATH expression identifying the
    top-level data model node that this access applies
 group-list is a list of group names granted access

For example, root is given all access to the path 'users/user':

<data-access>
  <operation-list>all</operation-list>
  <data-namespace>http://example.com/1.0</data-namespace>
  <data-path>/top/users/user</data-path>
  <group-list>root</group-list>
</data-access>


Multiple overlapping entries need to be handled
and a sequential processing model needs to be defined,
but IMO this type of simple approach could be good enough to
start with.

> David Harrington
> dbharrington@comcast.net
>  

Andy

>  


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