Subject: [Netconf] xml access control vs. netconf access control

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Nov 2010 01:20:24 +0100

Hi,

Bert mentioned today that we should look into XML access control work
and see if/how this applies to NETCONF. One often cited XML access
control piece of work is XACML defined by OASIS [1]. There has been
a paper on how to use XACML for NETCONF [2]. There has also been 
some academic work where they decided against XACML [3].

Of course, the NETCONF ACM applies to the NETCONF configuration
database and to operations invoked by NETCONF; the ACM does not apply
to the XML serialization used on the wire. NETCONF is not an XML
database - it is a protocol that just happens to use XML to encode
messages.

/js

[1] http://www.oasis-open.org/committees/xacml/
[2] http://eprints.sics.se/2905/01/report.pdf
[3] http://dx.doi.org/10.1109/TNSM.2006.4798304

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Nov 2010 17:53:30 -0800

> some academic work where they decided against XACML [3].

Thanks for finding this.
I have not read [2] completely, but my initial reaction is that
the configuration of access control rules is way too complicated.

My main goal is to provide a solution that covers all aspects of
NETCONF server behavior that is as easy as possible to configure.
Pilot error due to excessive complexity is a real concern, especially
for security configuration.

> database - it is a protocol that just happens to use XML to encode

agreed

> /js

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 09 Nov 2010 11:12:51 +0800

Thanks for finding these.

I'll check them out, or at least take a peak at them

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Nov 2010 11:32:16 +0800

> database - it is a protocol that just happens to use XML to encode

XML is not just the serialized form. I assume the NETCONF database has
to be modelled (at least conceptually) as XML infoset because we use
XPath to query it etc.

This is not to say that XACML is of any use. On the other hand, access
control models of other hierarchical databases such as LDAP could be
considered.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Nov 2010 20:24:06 -0800

On 11/08/2010 07:32 PM, Ladislav Lhotka wrote:
> ll

There are corner cases where a NETCONF server may not support all XPath
expressions the same way, as documented in the YANG Usage Guidelines.

> control models of other hierarchical databases such as LDAP could be

We are using XPath to specify the data rules.
We have optimizations that address specific NETCONF operational requirements.

The easy part is specifying an ACL.
The hard part is specifying the procedures a server must follow
so that the same ACL on 2 different servers produces the same NETCONF
protocol behavior.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Nov 2010 16:03:15 +0800

> expressions the same way, as documented in the YANG Usage Guidelines.

My point is that a NETCONF database in fact looks and behaves pretty
much like XML and the mapping to serialized XML is straightforward, so I
think "NETCONF is not XML" in not a valid reason for rejecting XACML
(though I don't advocate it because I haven't read the spec).

> so that the same ACL on 2 different servers produces the same NETCONF

Right, and I reckon LDAP servers must have implemented solutions to some
of these problems.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 09 Nov 2010 11:07:52 +0000

On 11/09/10 08:03, Ladislav Lhotka wrote:
> (though I don't advocate it because I haven't read the spec)
In addition  NETCONF/YANG also has user defined RPCs. Could be a tricky part of ACL especially 
if you don't want to define an ACL rule for each RPC.

IMHO getting the operator to use ACL is an  even bigger task then defining the ACL methodology 
(see VACM in SNMP). So simplicity is the king.

Balazs