Subject: Re: [NGO] Access control for NETCONF

From: Ludwig Seitz <[email-masked]>
Date: Tue, 03 Jul 2007 12:23:24 +0200

Comments inline.

Regards,

Ludwig Seitz

On Fri, 2007-06-29 at 05:49 -0700, Andy Bierman wrote:
> Ludwig Seitz wrote:
> > Hello,
> >          
> >         We have uploaded an Internet draft about access control for
> >         netconf. It can be found here:
> >         
> >         http://www.ietf.org/internet-drafts/draft-seitz-netconf-xacml-00.txt
...
> >         One of the activities in this project has been to address the
> >         problem how to perform access control without complete knowledge
> >         of the data model, with netconf as a concrete target protocol.
> >         Another requirement was to use some established general standard
> >         for access control policies, to avoid reinventing the wheel and
> >         in an attempt to reduce the number of access control languages
> >         that an administrator needs to learn.
> >         
> >         We have previous experience with a standardized access control
> >         language called XACML (the eXtensible Access Control Markup
> >         Language), and we have chosen to use XACML because it complied
> >         with these requirements.
> 
> Which requirements?
> 

1. Perform access control without complete knowledge of the data model.
Although the knowledge about data model is necessary to write the
concrete the access control policies, it is sometimes believed to be
necessary to make the access control decision or to design the access
control model. We show that this is not the case and which (1) allows to
separate the design of data model and access control solution and (2)
simplify the processing of access control requests.

2. Use some established general standard for access control policies. 
We use security standards for a range of reasons: to avoid re-inventing
the wheel, to decrease risk for design mistakes inherent to proprietary
solutions, to decrease the risk of configuration mistakes due to
misunderstandings in weakly defined systems, to enhance interoperability
and so forth. 

> There are several drafts on NETCONF Access Control now,
> and none of them has attempted to specify any real NETCONF
> access control requirements.
>
> What are the use cases driving specific features in a generalized solution?

Agreed, requirements and use cases are important. Our work so far has
been mostly research oriented and based on more general desirable
features such as flexibility and data model independence, rather than
very concrete implementation requirements or an analysis of the
specific problems of a NETCONF application. We would however very much
appreciate a discussion on requirements.

> Unless there is some agreement on the problem space, I don't see how
> the IETF can work on a solution.
> 
> >         
> >         XACML is an OASIS standard and is an XML based access control

[...]

> >         
> >         We have mapped the core netconf operations into a vocabulary
> >         of XACML attributes and are able to express access control
> >         policies for netconf in XACML.
> 
> IMO, this is really overkill for NETCONF.
> XACML has massive flexibility, but at a big cost in complexity.
> Experience with VACM in SNMP has shown that flexibility at the cost
> of complexity deterred deployment in all cases, even the simple ones.

We think flexibility is good since it allows the same access control
model to be used over time without the need to go back and patch up a
simplistic model in order to meet new requirements. Of course, we
wouldn't want to push for an overly complex model either. Finding out
the balance is what research is for, and we certainly hope we will not
be on our own in this. :-)

We believe that the XACML based model is not too complex to be usable. 
Most access control models (e.g. RBAC) map quite simply to XACML. 
We also believe that the more complex features will be useful. For
instance, imagine that network management will be integrated into large
SOA based workflows in the future. In such a system, when a customer
orders a networked service on a web site, this triggers the deployment
of the service and associated changes in the network configuration.
Having a flexible policy model will make that integration simpler since
the whole workflow can share the access control model.

[...]
> 
> This solution relies on an Xpath expression (same as every other proposal)
> to identify the data model subtree associated with the access rule.
> IMO, only NETCONF Object Identifiers (/interfaces/interface/ifMtu)
> and NETCONF Instance Identifiers (/interfaces/interface[ifName='eth0']/ifMtu)
> can be used safely in an ACM.
> 

We agree with that assessment, and there should be no problem in restricting the
XPath expressions used in XACML policies for Netconf to such a subset.
In fact we even suggest possible alternatives in section 6 of the draft.
We believe that this is a very similar issue as with the XACML complexity:
It would be a bad idea to define a proprietary, simple matching language,
that will be hard to extend later in the light of new requirements. Instead 
we would recommend to define a subset of XPath for use in Netconf access 
control and create policy templates that enforce this subset.

-- 
Ludwig Seitz
Ph.D., Researcher
Security, Policy and Trust Laboratory (SPOT)
Swedish Institute of Computer Science (SICS)
homepage: http://www.sics.se/~ludwig
_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Jul 2007 13:07:16 +0200

See in-line. 

Dan

> -----Original Message-----
> From: Ludwig Seitz [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 1:23 PM
> To: [email-masked]
> Subject: Re: [NGO] Access control for NETCONF
> 
> Comments inline.
> 
> Regards,
> 
> Ludwig Seitz
> 
> 
> Although the knowledge about data model is necessary to write 
> the concrete the access control policies, it is sometimes 
> believed to be necessary to make the access control decision 
> or to design the access control model. We show that this is 
> not the case and which (1) allows to separate the design of 
> data model and access control solution and (2) simplify the 
> processing of access control requests.
> 
> We use security standards for a range of reasons: to avoid 
> re-inventing the wheel, to decrease risk for design mistakes 
> inherent to proprietary solutions, to decrease the risk of 
> configuration mistakes due to misunderstandings in weakly 
> defined systems, to enhance interoperability and so forth. 

(as AD) It may have been better to separate the requirements in a short
document that can be discussed stand-alone, and would drive the
discussion of the solutions. 

> 
> > There are several drafts on NETCONF Access Control now, and none of 
> > them has attempted to specify any real NETCONF access control 
> > requirements.
> >
> Agreed, requirements and use cases are important. Our work so 
> far has been mostly research oriented and based on more 
> general desirable features such as flexibility and data model 
> independence, rather than very concrete implementation 
> requirements or an analysis of the specific problems of a 
> NETCONF application. We would however very much appreciate a 
> discussion on requirements.

(as contributor) - I am missing a requirement and discussion about the
granularity of the Access Control model. 

> > Experience with VACM in SNMP has shown that flexibility at 
> the cost of 
> > complexity deterred deployment in all cases, even the simple ones.
> 
> We think flexibility is good since it allows the same access 
> control model to be used over time without the need to go 
> back and patch up a simplistic model in order to meet new 
> requirements. Of course, we wouldn't want to push for an 
> overly complex model either. Finding out the balance is what 
> research is for, and we certainly hope we will not be on our 
> own in this. :-)

(as AD and contributor) This is more than a subject of research, this is
an issue that needs to be deployed and experimented. There are several
ways of doing this, one would be to publish specification documents and
push them on an experimental track, another to make prototypes available
for experimentation, or a combination of those. The sooner the better. 

> We also believe that the more complex features will be 
> useful. For instance, imagine that network management will be 
> integrated into large SOA based workflows in the future. In 
> such a system, when a customer orders a networked service on 
> a web site, this triggers the deployment of the service and 
> associated changes in the network configuration.
> Having a flexible policy model will make that integration 
> simpler since the whole workflow can share the access control model.

(as contributor) So, you believe that integration in a more complex
network management framework or SOA based workflow is a requirement for
the ACM? I believe that I understand what you try to say here, but I
doubt it should be a priority, in a first phase in any case. 
 
> 
> [...]
> > 
> > This solution relies on an Xpath expression (same as every other 
> > proposal) to identify the data model subtree associated 
> with the access rule.
> > IMO, only NETCONF Object Identifiers 
> (/interfaces/interface/ifMtu) and 
> > NETCONF Instance Identifiers 
> > (/interfaces/interface[ifName='eth0']/ifMtu)
> We agree with that assessment, and there should be no problem 
> in restricting the XPath expressions used in XACML policies 
> for Netconf to such a subset.
> It would be a bad idea to define a proprietary, simple 
> matching language, that will be hard to extend later in the 
> light of new requirements. Instead we would recommend to 
> define a subset of XPath for use in Netconf access control 
> and create policy templates that enforce this subset.
> 
> --
> Ludwig Seitz
> Ph.D., Researcher
> Security, Policy and Trust Laboratory (SPOT) Swedish 
> Institute of Computer Science (SICS)