Network Working Group L. Seitz
Internet-Draft SICS, Swedish Institute of
Intended status: Standards Track Computer Science AB
Expires: April 6, 2008 E. Rissanen
Axiomatics AB
October 4, 2007
NETCONF access control profile for XACML
draft-seitz-netconf-xacml-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 6, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Seitz & Rissanen Expires April 6, 2008 [Page 1]
Internet-Draft NETCONF access control profile for XACML October 2007
Abstract
The NETCONF remote network configuration protocol currently lacks an
access control model. The need for such a model has been recognised
within the NETCONF working group. The eXtended Access Control Markup
Language (XACML) is an XML-based access control standard, with
widespread acceptance from the industry and good open-source support.
This document proposes a profile that defines how to use XACML to
provide fine-grain access control for NETCONF commands.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. XACML overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4. NETCONF overview . . . . . . . . . . . . . . . . . . . . . . . 7
5. Policy and Request profile for XACML . . . . . . . . . . . . . 8
5.1. Abbreviations and namespaces . . . . . . . . . . . . . . . 8
5.2. New XACML functions, attributes and data-types . . . . . . 8
5.3. get and get-config RPC . . . . . . . . . . . . . . . . . . 10
5.4. edit-config RPC . . . . . . . . . . . . . . . . . . . . . 13
5.5. copy-config and delete-config RPC . . . . . . . . . . . . 16
5.6. lock and unlock RPC . . . . . . . . . . . . . . . . . . . 19
5.7. kill-session RPC . . . . . . . . . . . . . . . . . . . . . 21
5.8. close-session RPC . . . . . . . . . . . . . . . . . . . . 22
5.9. commit and discard-changes RPC . . . . . . . . . . . . . . 23
5.10. validate RPC . . . . . . . . . . . . . . . . . . . . . . . 24
6. Practical consequences for NETCONF implementations . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Abbreviations . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Get-config example . . . . . . . . . . . . . . . . . . . . 30
B.2. edit-config example . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42
Seitz & Rissanen Expires April 6, 2008 [Page 2]
Internet-Draft NETCONF access control profile for XACML October 2007
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Seitz & Rissanen Expires April 6, 2008 [Page 3]
Internet-Draft NETCONF access control profile for XACML October 2007
2. Introduction
The NETCONF protocol rfc [RFC4741] specifies in its Security
Considerations (section 9) that "This document does not specify an
authorization scheme, ... Implementors SHOULD provide a
comprehensive authorization scheme with NETCONF". In this document a
profile is defined and explained that allows to use the eXtended
Access Control Markup Language [XACML] as authorization scheme for
NETCONF commands. The reasons why the use of XACML is suggested are
the following:
o XACML is an open standard that has been developed by an industry
consortium.
o XACML is an XML [XML] based approach, that is well adapted to the
authorization challenges encountered within NETCONF.
o XACML is widely accepted and used in a number of commercial
products [XACMLProducts].
o Open-source implementations of the XACML standard are readily
available.
Seitz & Rissanen Expires April 6, 2008 [Page 4]
Internet-Draft NETCONF access control profile for XACML October 2007
3. XACML overview
This section gives a short overview of what XACML is and how it
works. We only describe the parts of XACML that are needed in this
draft, therefore some descriptions may not reflect the full
functionality of the corresponding XACML element. Some familiarity
with the terms from [RFC2904] (e.g. PDP, PEP) is expected from the
reader. The references also include a more detailed introduction
[XACMLIntro].
The XACML standard defines two things:
o A XML schema defining a syntax for requests, access control
policies and responses.
o A processing model that specifies how a request shall be evaluated
by a PDP against a set of policies in order to generate a
response.
A request is a collection of attributes typically describing the
requesting subject, the requested resource and the action that the
subject wishes to perform on the resource. An attribute can for
example be a role of the user or a resource group-id.
A policy consists of a target and one or more rules generating an
effect. The target describes for which request the policy applies,
in terms of conditions on a set of attributes. During evaluation
these attributes are fetched from the request and from external
information sources (PIPs) available to the PDP. If a policy
applies, its effect will either be PERMIT or DENY.
An example policy target is shown here:
01 <Target>
02 <AnyOf>
03 <AllOf>
04 <Match MatchId="&string-equal;">
05 <AttributeValue DataType="&string;">print</AttributeValue>
06 <AttributeDesignator Category="&Action;"
07 AttributeId="&resource-id;"
08 DataType="&string"/>
09 </Match>
10 <Match ... > ... </Match>
11 </AllOf>
12 <AllOf>...</AllOf>
13 </AnyOf>
14 <AnyOf> ... </AnyOf>
15 </Target>
Seitz & Rissanen Expires April 6, 2008 [Page 5]
Internet-Draft NETCONF access control profile for XACML October 2007
The Target consists of one or more AnyOf sections which must all be
fulfilled in order for the policy to apply. Within the AnyOf
section, one of the AllOfs must apply. Within a AllOf, all of the
Matches must apply. A Match specifies a matching function (which
must have a boolean result), and the function parameters, which can
either be static AttributeValue (as in line 04) or a value fetched
externally from the request of a PIP (as in line 05-07). The
AttributeDesignator (lines 05-07) specifies which external value(s)
to fetch by giving a Category, an Identifier and a DataType. If
several values are returned, only one needs to satisfy the Match
function.
Seitz & Rissanen Expires April 6, 2008 [Page 6]
Internet-Draft NETCONF access control profile for XACML October 2007
4. NETCONF overview
The NETCONF configuration protocol describes a set of operations that
read or write configuration data on a network device. These
operations are transferred to the device by the means of remote
procedure calls (RPCs) encoded in XML. The different protocol
operations are:
o <get-config> allows to get specific parts of a specific
configuration.
o <edit-config> allows to edit specific parts of a specific
configuration.
o <copy-config> allows to overwrite a specific configuration with a
new one from a specific source.
o <delete-config> allows to delete a specific configuration.
o <lock> allows to lock a specific configuration for editing.
o <unlock> allows to unlock a specific configuration.
o <get> allow to get specific parts from the "running"
configuration.
o <close-session> allows to close your own session.
o <kill-session> allows to kill someone else's session.
For a more specific description of the NETCONF protocol please refer
to [RFC4741].
The present document defines an access control model for these
operations and for the extensions defined in the standard.
Seitz & Rissanen Expires April 6, 2008 [Page 7]
Internet-Draft NETCONF access control profile for XACML October 2007
5. Policy and Request profile for XACML
The goal of this section is to define how a PEP SHOULD generate a
XACML request from a RPC carrying a NETCONF operation. The response
to this request determines whether the RPC is processed or discarded.
Furthermore this profile defines how policies corresponding to
permissions about a specific NETCONF operation on specific data
SHOULD be formulated. A strong familiarity with the latest XACML
syntax is required to fully appreciate this section.
The part of XACML authorisation that deals with the subjects (e.g. in
terms of user groups or roles) is out of scope for this profile,
since it is not in any way specific to the NETCONF protocol. Thus
all the following definitions omit the subject parts of both requests
and policies (indicated by "..."). This part can be defined
independently from this profile.
5.1. Abbreviations and namespaces
Since XML in general, and especially the XACML syntax, are quite
verbose we have defined a set of abbreviations, that can be found in
section Appendix A. Furthermore we use the term 'Attribute'
exclusively for XACML attributes. If we refer to attributes of XML
elements we specify this by adding the prefix 'XML' as in 'XML-
attribute'.
In order to clearly identify new XACML functions, attributes, and
data-types defined specifically for this profile they SHALL have the
identifier-prefix "xacml-netconf". Thus the following identifiers-
prefixes SHALL be used:
o Functions: "xacml-netconf:function:"
o Attributes: "xacml-netconf:attribute:"
o Data-types: "xacml-netconf:data-type:"
5.2. New XACML functions, attributes and data-types
This section defines the new functions, attributes and data-types for
XACML introduced by this profile.
o XACML function: Id="xacml-netconf:function:xpath-node-match"
Parameter 1 data-type: &xpath;
Parameter 2 data-type: &xpath;
The basic idea of this function is to check whether a xml-node in
a xml-document is matched by a certain XPath [XPath]. Due to the
Seitz & Rissanen Expires April 6, 2008 [Page 8]
Internet-Draft NETCONF access control profile for XACML October 2007
difficulty of encoding a xml-node in its document context, we use
a second XPath to point to that xml-node in the document.
This function works in two steps. First it evaluates the second
xpath (representing the xml-node) against the Content element of
the Request. This XPath must match a single xml-node only
(otherwise an error is returned).
In the second step, the first XPath expression is evaluated
against the same Content. If the resulting set of xml-nodes
contains the xml-node that results from the first step or one of
its ancestors, the value of this function is true, otherwise it is
false.
The following example shall illustrate how this function works:
Given the function parameters:
<xpath>/top/interfaces[name="Ethernet"]/interface</xpath> and
<xpath>/top/interfaces[name="Ethernet"]/interface</xpath>
as well as the content XML document:
01 <top>
02 <interfaces>
03 <name>Ethernet</name>
04 <interface>
05 <name>Ethernet0/0</name>
06 <mtu>1500</mtu>
07 </interface>
08 <interface>
09 <name>Ethernet1/1</name>
10 <mtu>3000</mtu>
11 </interface>
12 <interface>
13 <name>Ethernet2/2</name>
14 <mtu>1000</mtu>
15 </interface>
16 </interfaces>
17 <interfaces>
18 <name>WLAN</name>
19 <interface>
20 <name>DHCP0/0</name>
21 </interface>
22 </interfaces>
23 </top>
We get the following evaluation:
1. The second xpath points out the xml-node at line 09.
2. The first xpath points out the xml-nodes 03, 07 and 11.
Since xml-node 07 is an ancestor of xml-node 09 the function
evaluates to true.
Seitz & Rissanen Expires April 6, 2008 [Page 9]
Internet-Draft NETCONF access control profile for XACML October 2007
o XACML attribute: Id="xacml-netconf:attribute:rpc-target"
Category=&Resource;
data-type=&string;
This attribute indicates which data store the operation is
targeting. In the case of the copy-config command, this is the
destination data store. For the lock/unlock commands this is the
target data store. An example value would be "running".
o XACML attribute: Id="xacml-netconf:attribute:rpc-source"
Category=&Resource;
data-type=&string; or data-type=&AnyURI;
This attribute indicates the source for the operation. In the
case of the copy-config command, this is the source data store or
an URL. An example value would be "candidate".
o XACML data-type: Id="xacml-netconf:data-type:xpath-expression"
This data-type is a XPath. The data-type also encodes necessary
namespace information, if the XPath is to be used on a namespace
aware document. The encoding is an XML-tag with the name of
"xpath" containing zero or more attributes, each defining a
namespace prefix to namespace URI matching for use with this
XPath.
An example xpath expression would look like this:
01 <AttributeValue DataType="&xpath;">
02 <xpath xmlns:ns1="http://example.com/schema/1.2/config">
03 //ns1:top/ns1:interfaces[ns1:name="Ethernet"]
04 </xpath>
05 </AttributeValue>
5.3. get and get-config RPC
The get/get-config RPCs get a special treatment, because it was
deemed that the whole RPC shouldn't fail just because the the user is
not authorised to read parts of the result. Instead the desired
behaviour in such a case is to prune the results that are not covered
by the users rights. Therefore it is RECOMMENDED to perform access
control on the result of a get/get-config RPC instead of on the RPC
itself, so that the unauthorised elements can be filtered out and
only the authorised ones remain.
Requests for get/get-config RPCs SHALL be formed as follows: As a
first step, calculate which xml-nodes of the data model are the
results of the RPC. For each xml-node in the result, run an XACML
request. The request contains
Seitz & Rissanen Expires April 6, 2008 [Page 10]
Internet-Draft NETCONF access control profile for XACML October 2007
1. The whole result document under the <Content> xml-node.
2. A "&Resource;" category Attribute with AttributeId=&resource-id;
having the AttributeValue of DataType="&xpath;" which contains an
XPath that uniquely identifies the xml-node in question.
3. Another &Resource; category Attribute with AttributeId="xacml-
netconf:attribute:rpc-source" and the AttributeValue with
DataType="&string;" that identifies the data-model this RPC uses
as source (i.e. "running", "startup" or "candidate")
corresponding to the RPC source. This SHALL always have a value
of "running" for "get" RPCs.
4. An "Action" category Attribute with AttributeId="action-id" and
the AttributeValue "read" with DataType="&string;".
Each xml-node that is permitted by the corresponding request is
included in the result together with its ancestors and descendants.
Furthermore the requests for its descendants are skipped. Those xml-
nodes that are not permitted are not included.
These multiple XACML requests can be executed very efficiently if the
PDP is running locally on the network element, preferably in the same
process as the NETCONF agent. Such an architecture would mean that
no new XML documents get generated and no network communication needs
to be done for those repeated requests.
For security reasons it is advisable not to report that parts of the
response where pruned by access control, otherwise an attacker could
use get/get-config to gather information about the existence of parts
of the configuration that is not accessible according to the
attackers rights.
It is RECOMMENDED that a policy designed to apply to a get or get-
config RPC SHOULD match one AttributeValue corresponding to the
desired subtree of the data-model with the DataType="&xpath;", the
AttributeId="&resource-id;" and the Category="&Resource;".
The same <AllOf> element SHOULD contain a match of an AttributeValue
corresponding to the desired RPC source (i.e. "running", "startup" or
"candidate") with the DataType="&string;", the AttributeId="xacml-
netconf:attribute:rpc-source" and the Category="&Resource;". If the
policy is to apply to "get" RPCs only this value SHOULD be "running"
Furthermore the policy SHOULD match the AttributeValue "read" with
the DataType="&string;", the AttributeId="action-id" and the
Category="Action". in a <AllOf> element enclosed by a separate
<AnyOf> element of the policy target.
Example request:
Seitz & Rissanen Expires April 6, 2008 [Page 11]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath xmlns:ns1="http://example.com/schema/config">
07 /ns1:top[1]/ns1:interface[1]
08 </xpath>
09 </AttributeValue>
10 </Attribute>
11 <Attribute AttributeId="xacml-netconf:attribute:rpc-source">
12 <AttributeValue DataType="&string;>running</AttributeValue>
13 </Attribute>
14 </Attributes>
15 <Attributes Category="Action">
16 <Attribute AttributeId="action-id">
17 <AttributeValue DataType="&string;">read</AttributeValue>
18 </Attribute>
19 </Attributes>
20 <Content>
21 <top xmlns="http://example.com/schema/config">
22 <interface>
23 <name>Ethernet0/0</name>
24 <mtu>1500</mtu>
25 </interface>
26 <interface>
27 <name>Ethernet1/1</name>
28 <mtu>1000</mtu>
29 </interface>
30 </top>
31 </Content>
32 </Request>
Example policy:
Seitz & Rissanen Expires April 6, 2008 [Page 12]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Policy PolicyId="ex1" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="xacml-netconf:function:xpath-node-match">
07 <AttributeValue DataType="&xpath;">
08 <xpath xmlns:ns1="http://example.com/schema/config">
09 /ns1:top/ns1:interface
10 </xpath>
11 </AttributeValue>
12 <AttributeDesignator Category="&Resource;"
13 AttributeId="&resource-id;"
14 DataType="&xpath;"/>
15 </Match>
16 <Match MatchId="&string-equal;">
17 <AttributeValue
18 DataType="&string;">running</AttributeValue>
19 <AttributeDesignator Category="&Resource;"
20 AttributeId="xacml-netconf:attribute:rpc-source"
21 DataType="&string;"/>
22 </Match>
23 </AllOf>
24 </AnyOf>
25 <AnyOf>
26 <AllOf>
27 <Match MatchId="&string-equal;">
28 <AttributeValue DataType="&string;">read</AttributeValue>
29 <AttributeDesignator Category="Action"
30 AttributeId="action-id"
31 DataType="&string;"/>
32 </Match>
33 </AllOf>
34 </AnyOf>
35 </Target>
36 <Rule RuleId="PermitRule" Effect="Permit"/>
37 </Policy>
5.4. edit-config RPC
Requests for edit-config RPCs SHALL be formed as follows: Under the
<Attributes Category="&Resource;"> element an Attribute with the
AttributeId="&resource-id;" and the DataType="&xpath;". The
AttributeValue SHALL be "//*[@operation and not(ancestor::*[@
operation])]".
The same Category SHALL also include an Attribute with the
AttributeId="&scope;" and the DataType="&string;". The
AttributeValue SHALL be "XPath-expression".
Seitz & Rissanen Expires April 6, 2008 [Page 13]
Internet-Draft NETCONF access control profile for XACML October 2007
Still under the same Category there SHALL be an Attribute with the
AttributeId="xacml-netconf:attribute:rpc-target" and the DataType="&
string;". The AttributeValue SHALL be either "running", "startup" or
"candidate" corresponding to the RPC target.
Furthermore the request SHALL include the <Attributes
Category="Action"> element, containing a single Attribute with the
AttributeId="action-id" having the DataType="&string;" and the
AttributeValue of "write".
From the RPC, the contents of the <config> element SHALL be included
in the request under the <Content> element. If the RPC contains a
<default-operation> element the contents of the RPC <config> element
that are added to the request <Content> element SHALL be edited to
add a xml-attribute "operation" with a value corresponding to the
value of the <default-operation> element.
This request format makes use of the Multiple resource profile of
XACML [XACML_MR] where the multiple resources are the elements of the
RPC that have an "operation" xml-attribute and no ancestor with such
an xml-attribute. Using this profile, no access control is performed
for operations that have an ancestor operation. This is due to the
fact that all edit-config operations are subsumed under the action
"write" as far as access control is concerned. The underlying
assumption of this profile is that if you are authorised to write to
a xml-node in the data-model you are automatically authorised to
write to all its children too.
The XPath "//*[@operation and not(ancestor::*[@operation])]" performs
the selection of operations with no ancestor operation.
If any edit-config operation of the RPC is not permitted, the whole
RPC SHALL be denied.
If the RPC uses the :url capability (i.e. a <url> element appears
instead of the <config> element), the NETCONF agent SHALL preprocess
the RPC by downloading the file pointed to by the URL and replacing
the <url> element by a <config> element containing the content of the
file.
Another special case that needs to be treated is the following:
According to the protocol specification, it is possible to create a
syntactically correct edit-config RPC with no operation at all (i.e.
specifying 'none' as <default-operation> and having no 'operation'
xml-attributes in the <content>). Such an RPC SHALL be discarded
according to this profile and not be processed by the NETCONF agent,
to avoid leaking information with the error messages.
It is RECOMMENDED that a policy designed to apply to an edit-config
RPC SHOULD match one AttributeValue corresponding to the desired
subtree of the data-model with the DataType="&xpath;", the
AttributeId="&resource-id;" and the Category="&Resource;".
The same <AllOf> element SHOULD contain a match of an AttributeValue
corresponding to the desired RPC target (i.e. "running", "startup" or
Seitz & Rissanen Expires April 6, 2008 [Page 14]
Internet-Draft NETCONF access control profile for XACML October 2007
"candidate") with the DataType="&string;", the AttributeId="xacml-
netconf:attribute:rpc-target" and the Category="&Resource;".
Furthermore the policy SHOULD match the AttributeValue "write" with
the DataType="&string;", the AttributeId="action-id" and the
Category="Action" in a <AllOf> element enclosed by a separate <AnyOf>
element of the policy target.
Example request:
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath>
07 //*[@operation and not(ancestor::*[@operation])]
08 </xpath>
09 </AttributeValue>
10 </Attribute>
11 <Attribute AttributeId="&scope;">
12 <AttributeValue
13 DataType="&string;>XPath-expression</AttributeValue>
14 </Attribute>
15 <Attribute AttributeId="xacml-netconf:attribute:rpc-target">
16 <AttributeValue DataType="&string;>running</AttributeValue>
17 </Attribute>
18 </Attributes>
19 <Attributes Category="Action">
20 <Attribute AttributeId="action-id">
21 <AttributeValue DataType="&string;">write</AttributeValue>
22 </Attribute>
23 </Attributes>
24 <Content>
25 <top xmlns="http://example.com/schema/config">
26 <interface xc:operation="replace">
27 <name>Ethernet0/0</name>
28 <mtu>1500</mtu>
29 </interface>
30 </top>
31 </Content>
32 </Request>
Example policy:
Seitz & Rissanen Expires April 6, 2008 [Page 15]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Policy PolicyId="ex2" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="xacml-netconf:function:xpath-node-match">
07 <AttributeValue DataType="&xpath;">
08 <xpath xmlns:ns1="http://example.com/schema/config">
09 /ns1:top/ns1:interface[ns1:name="Ethernet0/0"]
10 </xpath>
11 </AttributeValue>
12 <AttributeDesignator Category="&Resource;"
13 AttributeId="&resource-id;"
14 DataType="&xpath;"/>
15 </Match>
16 <Match MatchId="&string-equal;">
17 <AttributeValue
18 DataType="&string;">running</AttributeValue>
19 <AttributeDesignator Category="&Resource;"
20 AttributeId="xacml-netconf:attribute:rpc-target"
21 DataType="&string;"/>
22 </Match>
23 </AllOf>
24 </AnyOf>
25 <AnyOf>
26 <AllOf>
27 <Match MatchId="&string-equal;">
28 <AttributeValue
29 DataType="&string;">write</AttributeValue>
30 <AttributeDesignator Category="Action"
31 AttributeId="action-id"
32 DataType="&string;"/>
33 </Match>
34 </AllOf>
35 </AnyOf>
36 </Target>
37 <Rule RuleId="PermitRule" Effect="Permit"/>
38 </Policy>
5.5. copy-config and delete-config RPC
Requests for copy-config and delete-config RPCs SHALL be formed as
follows: The RPC target parameter SHALL be included under the
<Attributes Category="&Resource;"> element as a single Attribute with
the AttributeId="xacml-netconf:attribute:rpc-target". If the RPC
target is one of {running, startup, candidate} the DataType SHALL be
"&string;" otherwise it SHALL be "&AnyURI;". The AttributeValue
SHALL be equal to the RPC target.
Seitz & Rissanen Expires April 6, 2008 [Page 16]
Internet-Draft NETCONF access control profile for XACML October 2007
In case of copy-config RPCs the request SHALL also include the RPC
source under same Category as a single Attribute with the
AttributeId="xacml-netconf:attribute:rpc-source". If the RPC source
is one of {running, startup, candidate} the DataType SHALL be
"&string;" otherwise it SHALL be "&AnyURI;". The AttributeValue
SHALL be equal to the RPC source.
Furthermore the request SHALL include the <Attributes
Category="Action"> element, containing a single Attribute with the
AttributeId="action-id" having the DataType="&string;". This SHALL
have the AttributeValue of "write" if the RPC target is one of
{running, startup, candidate}. If the RPC target is a URL then this
AttributeValue SHALL be "read".
When the target is a URL, no configuration data is overwritten, such
RPC must therefore be considered 'read' operations. However when the
target is a local configuration, the RPC must be considered a 'write'
operation.
It is RECOMMENDED that a policy designed to apply to a copy-config/
delete-config RPC SHOULD match one or more AttributeValues
corresponding to the desired RPC targets with AttributeId="xacml-
netconf:attribute:rpc-target" and the Category="&Resource;".
For those targets that are "running", "startup" or "candidate" the
DataType SHALL be equal to "&string;", for URL targets, the DataType
SHALL be equal to &AnyURI;.
Each desired RPC target SHOULD be placed in a separate <AllOf>
element under a single common <AnyOf> element in the policy target.
The policy SHOULD also match one or more AttributeValues
corresponding to the desired RPC sources with the DataType="&string;"
or DataType="&AnyURI;", the AttributeId="xacml-netconf:attribute:rpc-
source" and the Category="&Resource;". Each desired RPC source
SHOULD be placed in a separate <AllOf> element under a single common
<AnyOf> element in the policy target.
Furthermore if any target elements where one of {running, startup,
candidate}, then the policy SHOULD match the AttributeValue "write"
with the DataType="&string;", the AttributeId="action-id" and the
Category="Action" in a separate <AllOf> element enclosed by a
separate <AnyOf> element in the policy target.
If any source elements where one of {running, startup, candidate},
then the policy SHOULD match the AttributeValue "read" with the
DataType="&string;", the AttributeId="action-id" and the
Category="Action" in a separate <AllOf> element. This element should
be enclosed the same <AnyOf> element as previous "write" action
matches if any, otherwise it is to be enclosed by a separate <AnyOf>
element in the policy target.
Example request:
Seitz & Rissanen Expires April 6, 2008 [Page 17]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="xacml-netconf:attribute:rpc-target">
05 <AttributeValue DataType="&string;>running</AttributeValue>
06 </Attribute>
07 <Attribute AttributeId="xacml-netconf:attribute:rpc-source">
08 <AttributeValue DataType="&AnyURI;>https://user@example.com:
09 passphrase/cfg/new.txt</AttributeValue>
10 </Attribute>
11 </Attributes>
12 <Attributes Category="Action">
13 <Attribute AttributeId="action-id">
14 <AttributeValue DataType="&string;">write</AttributeValue>
15 </Attribute>
16 </Attributes>
17 </Request>
Example policy:
Seitz & Rissanen Expires April 6, 2008 [Page 18]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Policy PolicyId="ex3" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="&string-equal;">
07 <AttributeValue
08 DataType="&string;">running</AttributeValue>
09 <AttributeDesignator Category="&Resource;"
10 AttributeId="xacml-netconf:attribute:rpc-target"
11 DataType="&string;"/>
12 </Match>
13 </AllOf>
14 </AnyOf>
15 <AnyOf>
16 <AllOf>
17 <Match MatchId="&uri-equal;">
18 <AttributeValue
19 DataType="&AnyURI;">https://user@example.com:
20 passphrase/cfg/new.txt</AttributeValue>
21 <AttributeDesignator Category="&Resource;"
22 AttributeId="xacml-netconf:attribute:rpc-source"
23 DataType="&AnyURI;"/>
24 </Match>
25 </AllOf>
26 </AnyOf>
27 <AnyOf>
28 <AllOf>
29 <Match MatchId="&string-equal;">
30 <AttributeValue
31 DataType="&string;">write</AttributeValue>
32 <AttributeDesignator Category="Action"
33 AttributeId="action-id"
34 DataType="&string;"/>
35 </Match>
36 </AllOf>
37 </AnyOf>
38 </Target>
39 <Rule RuleId="PermitRule" Effect="Permit"/>
40 </Policy>
5.6. lock and unlock RPC
Requests for lock/unlock RPCs SHALL be formed as follows: The RPC
operation target SHALL be included under the <Attributes Category="&
Resource;"> element as a single Attribute with the
AttributeId="xacml-netconf:attribute:rpc-target" and the DataType="&
string;". The AttributeValue SHALL be either "running", "startup" or
Seitz & Rissanen Expires April 6, 2008 [Page 19]
Internet-Draft NETCONF access control profile for XACML October 2007
"candidate" corresponding to the RPC operation target.
Furthermore the request SHALL include the <Attributes
Category="Action"> element, containing a single Attribute with the
AttributeId="action-id" having the DataType="&string;" and the
AttributeValue of either "lock" or "unlock" depending on the type of
RPC.
It is RECOMMENDED that a policy designed to apply to a lock/unlock
RPC SHOULD match one or more AttributeValues corresponding to the
desired RPC targets (i.e. "running", "startup" and/or "candidate")
with the DataType="&string;", the AttributeId="xacml-
netconf:attribute:rpc-target" and the Category="&Resource;". Each
desired RPC target SHOULD be placed in a separate <AllOf> element
under a single <AnyOf> element in the policy target. Furthermore the
policy SHOULD match both AttributeValues "lock" and "unlock" with the
DataType="&string;", the AttributeId="action-id" and the
Category="Action". in separate <AllOf> elements enclosed by a
separate <AnyOf> element of the policy target.
Example request:
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="xacml-netconf:attribute:rpc-target">
05 <AttributeValue DataType="&string;>running</AttributeValue>
06 </Attribute>
07 </Attributes>
08 <Attributes Category="Action">
09 <Attribute AttributeId="action-id">
10 <AttributeValue DataType="&string;">lock</AttributeValue>
11 </Attribute>
12 </Attributes>
13 </Request>
Example policy:
Seitz & Rissanen Expires April 6, 2008 [Page 20]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Policy PolicyId="ex4" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="&string-equal;">
07 <AttributeValue
08 DataType="&string;">running</AttributeValue>
09 <AttributeDesignator Category="&Resource;"
10 AttributeId="xacml-netconf:attribute:rpc-target"
11 DataType="&string;"/>
12 </Match>
13 </AllOf>
14 </AnyOf>
15 <AnyOf>
16 <AllOf>
17 <Match MatchId="&string-equal;">
18 <AttributeValue
19 DataType="&string;">lock</AttributeValue>
20 <AttributeDesignator Category="Action"
21 AttributeId="action-id"
22 DataType="&string;"/>
23 </Match>
24 </AllOf>
25 <AllOf>
26 <Match MatchId="&string-equal;">
27 <AttributeValue
28 DataType="&string;">unlock</AttributeValue>
29 <AttributeDesignator Category="Action"
30 AttributeId="action-id"
31 DataType="&string;"/>
32 </Match>
33 </AllOf>
34 </AnyOf>
35 </Target>
36 <Rule RuleId="PermitRule" Effect="Permit"/>
37 </Policy>
5.7. kill-session RPC
Requests and policies for this RPC are defined to be independent of
the session-id. Although it would be easily possible to make
session-id specific policies and requests, no reasonable use-case for
such a feature was found.
Any kill-session RPC SHALL be translated to a request that includes
the <Attributes Category="Action"> element, containing a single
Attribute with the AttributeId="action-id" having the DataType="&
Seitz & Rissanen Expires April 6, 2008 [Page 21]
Internet-Draft NETCONF access control profile for XACML October 2007
string;" and the AttributeValue "kill-session".
It is RECOMMENDED that a policy designed to apply to a kill-session
RPC SHOULD match the single AttributeValue "kill-session" with the
DataType="&string;", the AttributeId="action-id" and the
Category="Action" in a <AnyOf> element of its Target.
Example request:
01 <Request>
02 ...
03 <Attributes Category="Action">
04 <Attribute AttributeId="action-id">
05 <AttributeValue
06 DataType="&string;">kill-session</AttributeValue>
07 </Attribute>
08 </Attributes>
09 </Request>
Example policy:
01 <Policy PolicyId="ex5" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="&string-equal;">
07 <AttributeValue
08 DataType="&string;">kill-session</AttributeValue>
09 <AttributeDesignator Category="Action"
10 AttributeId="action-id"
11 DataType="&string;"/>
12 </Match>
13 </AllOf>
14 </AnyOf>
15 </Target>
16 <Rule RuleId="PermitRule" Effect="Permit"/>
17 </Policy>
5.8. close-session RPC
For this RPC it was deemed that no XACML profile was necessary. This
results from the assumption that only the person that opened a
session should be allowed to submit this RPC to the NETCONF agent.
It seems reasonable to expect that the NETCONF agent can enforce this
behaviour without the support of the access control system.
Seitz & Rissanen Expires April 6, 2008 [Page 22]
Internet-Draft NETCONF access control profile for XACML October 2007
5.9. commit and discard-changes RPC
If the NETCONF agent supports the :candidate capability, Any commit
or discard-changes RPC SHALL be translated to a request that includes
the <Attributes Category="Action"> element, containing a single
Attribute with the AttributeId="action-id" having the DataType="&
string;" and the AttributeValue of either "commit" or "discard-
changes".
It is RECOMMENDED that a policy designed to apply to a commit or
discard-changes RPC SHOULD match the single AttributeValue "commit"
or "discard-changes" with the DataType="&string;", the
AttributeId="action-id" and the Category="Action" in a <AllOf>
element enclosed by a <AnyOf> element of its Target.
Example request:
01 <Request>
02 ...
03 <Attributes Category="Action">
04 <Attribute AttributeId="action-id">
05 <AttributeValue DataType="&string;">commit</AttributeValue>
06 </Attribute>
07 </Attributes>
08 </Request>
Example policy:
01 <Policy PolicyId="ex6" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="&string-equal;">
07 <AttributeValue
08 DataType="&string;">commit</AttributeValue>
09 <AttributeDesignator Category="Action"
10 AttributeId="action-id"
11 DataType="&string;"/>
12 </Match>
13 </AllOf>
14 </AnyOf>
15 </Target>
16 <Rule RuleId="PermitRule" Effect="Permit"/>
17 </Policy>
Seitz & Rissanen Expires April 6, 2008 [Page 23]
Internet-Draft NETCONF access control profile for XACML October 2007
5.10. validate RPC
If the NETCONF agent supports the :validate capability, requests for
lock/unlock RPCs SHALL be formed as follows: The RPC operation target
SHALL be included under the <Attributes Category="&Resource;">
element as a single Attribute with the AttributeId="xacml-
netconf:attribute:rpc-target" and the DataType="&string;". The
AttributeValue SHALL be either "running", "startup" or "candidate"
corresponding to the RPC operation target.
Furthermore the request SHALL include the <Attributes
Category="Action"> element, containing a single Attribute with the
AttributeId="action-id" having the DataType="&string;" and the
AttributeValue of "validate".
It is RECOMMENDED that a policy designed to apply to a validate RPC
SHOULD match one or more AttributeValues corresponding to the desired
RPC targets (i.e. "running", "startup" and/or "candidate") with the
DataType="&string;", the AttributeId="xacml-netconf:attribute:rpc-
target" and the Category="&Resource;". Each desired RPC target
SHOULD be placed in a separate <AllOf> element under a single <AnyOf>
element in the policy target. Furthermore the policy SHOULD match
the AttributeValue "validate" with the DataType="&string;", the
AttributeId="action-id" and the Category="Action" in a separate
<AllOf> element enclosed by a separate <AnyOf> element of the policy
target.
Example request:
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="xacml-netconf:attribute:rpc-target">
05 <AttributeValue DataType="&string;>candidate</AttributeValue>
06 </Attribute>
07 </Attributes>
08 <Attributes Category="Action">
09 <Attribute AttributeId="action-id">
10 <AttributeValue DataType="&string;">validate</AttributeValue>
11 </Attribute>
12 </Attributes>
13 </Request>
Example policy:
Seitz & Rissanen Expires April 6, 2008 [Page 24]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Policy PolicyId="ex7" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="&string-equal;">
07 <AttributeValue
08 DataType="&string;">candidate</AttributeValue>
09 <AttributeDesignator Category="&Resource;"
10 AttributeId="xacml-netconf:attribute:rpc-target"
11 DataType="&string;"/>
12 </Match>
13 </AllOf>
14 </AnyOf>
15 <AnyOf>
16 <AllOf>
17 <Match MatchId="&string-equal;">
18 <AttributeValue
19 DataType="&string;">validate</AttributeValue>
20 <AttributeDesignator Category="Action"
21 AttributeId="action-id"
22 DataType="&string;"/>
23 </Match>
24 </AllOf>
25 </AnyOf>
26 </Target>
27 <Rule RuleId="PermitRule" Effect="Permit"/>
28 </Policy>
Seitz & Rissanen Expires April 6, 2008 [Page 25]
Internet-Draft NETCONF access control profile for XACML October 2007
6. Practical consequences for NETCONF implementations
This profile does not make any assumptions on the data-model that a
NETCONF operation affects. However writing a correct policy
according to this profile requires such knowledge. This is due to
the fact that XPathes matching parts of the data-model have to be
inserted in the policy.
A PDP using this profile to perform access control on NETCONF
operations will need access to the RPC and for <get> or <get-config>
operations, to the results of the RPC. No access to actual device
data is required by this profile. If a special treatment for get/
get-config proves to be undesirable, a more restrictive
interpretation can be implemented by performing a similar access
control evaluation as for edit-config RPCs.
This profile makes heavy use of XPath [XPath] to reference elements
in a data-model. It may be the case that XPath processing proves to
be too slow for time-critical applications. Therefore alternatives
can be considered, such as the Subtree Filtering proposed in the
Netconf standard section 6 [RFC4741]. This profile can be adapted to
such alternatives with relative ease, by creating a new data-type for
XACML representing the xml-node selection expression and a new
function for XACML equivalent to the "xpath-node-match" Function.
According to this profile, no specific access control architecture is
required (i.e. where the PDP and PEP are implemented). However it
seems both advisable and possible to have the PDP running at the same
location as the NETCONF agent. Although calls to distant PDPs are
possible the response time would be prohibitive. In order to allow
for fast communication one should aim to have the PDP running in the
same process as the NETCONF agent. Our implementation of the XACML
PDP is around 300 KByte large and has a memory consumption in the
order of magnitude of 700 KBytes (this is mostly due to XML
processing at startup). Further optimisation of these numbers is
possible if need arises.
If the NETCONF agent supports the :url capability, edit-config RPCs
need to be preprocessed to substitute a possible <url> element by a
<config> element containing the contents of the file pointed to by
the URL.
Seitz & Rissanen Expires April 6, 2008 [Page 26]
Internet-Draft NETCONF access control profile for XACML October 2007
7. Security Considerations
Depending on the error messages returned by unsuccessful edit-config
operations, an attacker might probe parts of the data model that are
not covered by the attackers access rights. Especially the 'data-
exists' and 'data-missing' errors could leak information about the
device data. If these leaks are considered severe, one should
consider replacing the error message e.g. with an 'operation-failed'
error message without further description.
New capabilities advertised by NETCONF agents can provide new methods
of accessing data on the device. If the access control model does
not cover such capabilities it is RECOMMENDED to deny requests using
them until the model has been extended to cover them.
In order to implement such behaviour for new NETCONF operations, a
deny-biased PDP can be used. Such a PDP denies all requests for
which no applicable policy can be found.
If the capability affects existing NETCONF operations, the specific
profile for these operations SHOULD be extended.
Security considerations from the XACML standard [XACML] and from the
NETCONF standard [RFC4741] SHOULD be applied to any use of this
profile.
Seitz & Rissanen Expires April 6, 2008 [Page 27]
Internet-Draft NETCONF access control profile for XACML October 2007
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904,
August 2000.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[XACML] OASIS, "eXtensible Access Control Markup Language",
<http://www.oasis-open.org/committees/xacml>.
[XACML_MR]
Anderson, A., "Multiple resource profile of XACML v2.0",
OASIS Standard, February 2005.
[XML] Bray, T., Paoli, J., Maler, E., Sperberg-McQueen, C., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.
[XPath] DeRose, S. and J. Clark, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
8.2. Informative References
[XACMLIntro]
Sun Microsystems, Inc., "A Brief Introduction to XACML",
Webpage http://www.oasis-open.org/committees/download.php/
2713/Brief_Introduction_to_XACML.html, March 2003.
[XACMLProducts]
Anderson, A., "XACML References and Products, Version
1.73",
Webpage http://docs.oasis-open.org/xacml/xacmlRefs.html,
January 2007.
Seitz & Rissanen Expires April 6, 2008 [Page 28]
Internet-Draft NETCONF access control profile for XACML October 2007
Appendix A. Abbreviations
For abbreviating XACML policies and requests this profile provides a
list of entity declarations, that is to be used within this document.
The syntax and expansion for such entities is defined in [XML] (e.g.
&string; will be expanded to
"http://www.w3.org/2001/XMLSchema#string").
o <!ENTITY permit-overrides "urn:oasis:names:tc:xacml:1.0:rule-
combining-algorithm:permit-overrides">
o <!ENTITY Resource
"urn:oasis:names:tc:xacml:3.0:attribute-category:resource" >
o <!ENTITY resource-id
"urn:oasis:names:tc:xacml:1.0:resource:resource-id" >
o <!ENTITY string "http://www.w3.org/2001/XMLSchema#string" >
o <!ENTITY string-equal
"urn:oasis:names:tc:xacml:1.0:function:string-equal" >
o <!ENTITY AnyURI "http://www.w3.org/2001/XMLSchema#anyURI" >
o <!ENTITY uri-equal
"urn:oasis:names:tc:xacml:1.0:function:anyURI-equal" >
o <!ENTITY xpath "xacml-netconf:data-type:data-type:xpath-
expression" >
o <!ENTITY scope "urn:oasis:names:tc:xacml:2.0:resource:scope" >
Seitz & Rissanen Expires April 6, 2008 [Page 29]
Internet-Draft NETCONF access control profile for XACML October 2007
Appendix B. Examples
In this section we give examples of requests, policies and their
evaluation.
B.1. Get-config example
Given the following get-config RPC:
01 <rpc message-id="101"
02 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
03 <get-config>
04 <source><running/></source>
05 <filter type="subtree">
06 <top>
07 <interfaces/>
08 </top>
09 </filter>
10 </get-config>
11 </rpc>
we get the following result before access control:
Seitz & Rissanen Expires April 6, 2008 [Page 30]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <rpc-reply message-id="101"
02 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
03 <data>
04 <top>
05 <interfaces>
06 <name>Ethernet</name>
07 <interface>
08 <name>Ethernet0/0</name>
09 <mtu>1500</mtu>
10 </interface>
11 <interface>
12 <name>Ehternet1/1</name>
13 <mtu>3000</mtu>
14 </interface>
15 <interface>
16 <name>Ethernet2/2</name>
17 <mtu>1000</mtu>
18 </interface>
19 </interfaces>
20 <interfaces>
21 <name>WLAN</name>
22 <interface>
23 <name>WLAN0/0</name>
24 </interface>
25 </interfaces>
26 </top>
27 </data>
28 </rpc-reply>
Now given and the XACML policy (omitting the subject part):
Seitz & Rissanen Expires April 6, 2008 [Page 31]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Policy PolicyId="ex8" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="xacml-netconf:function:xpath-node-match">
07 <AttributeValue DataType="&xpath;">
08 <xpath>/top/interfaces[name="Ethernet"]</xpath>
09 </AttributeValue>
10 <AttributeDesignator Category="&Resource;"
11 AttributeId="&resource-id;"
12 DataType="&xpath;"/>
13 </Match>
14 <Match MatchId="&string-equal;">
15 <AttributeValue
16 DataType="&string;">running</AttributeValue>
17 <AttributeDesignator Category="&Resource;"
18 AttributeId="xacml-netconf:attribute:rpc-source"
19 DataType="&string;"/>
20 </Match>
21 </AllOf>
22 </AnyOf>
23 <AnyOf>
24 <AllOf>
25 <Match MatchId="&string-equal;">
26 <AttributeValue
27 DataType="&string;">read</AttributeValue>
28 <AttributeDesignator Category="Action"
29 AttributeId="action-id"
30 DataType="&string;"/>
31 </Match>
32 </AllOf>
33 </AnyOf>
34 </Target>
35 <Rule RuleId="PermitRule" Effect="Permit"/>
36 </Policy>
we generate the following requests (omitting the subject part):
Seitz & Rissanen Expires April 6, 2008 [Page 32]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath>/top[1]</xpath>
07 </AttributeValue>
08 </Attribute>
09 <Attribute AttributeId="xacml-netconf:attribute:rpc-source">
10 <AttributeValue DataType="&string;>running</AttributeValue>
11 </Attribute>
12 </Attributes>
13 <Attributes Category="Action">
14 <Attribute AttributeId="action-id">
15 <AttributeValue DataType="&string;">read</AttributeValue>
16 </Attribute>
17 </Attributes>
18 <Content>
19 <top>...</top>
20 </Content>
21 </Request>
which is denied.
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath>/top[1]/interfaces[1]</xpath>
07 </AttributeValue>
08 </Attribute>
09 ...
10 </Request>
which is permitted.
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath>/top[1]/interfaces[2]</xpath>
07 </AttributeValue>
08 </Attribute>
09 ...
10 </Request>
Seitz & Rissanen Expires April 6, 2008 [Page 33]
Internet-Draft NETCONF access control profile for XACML October 2007
which is denied.
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath>/top[1]/interfaces[2]/name[1]</xpath>
07 </AttributeValue>
08 </Attribute>
09 ...
10 </Request>
which is denied.
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath>/top[1]/interfaces[2]/name[1]</xpath>
07 </AttributeValue>
08 </Attribute>
09 ...
10 </Request>
which is denied.
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath>/top[1]/interfaces[2]/interface[1]</xpath>
07 </AttributeValue>
08 </Attribute>
09 ...
10 </Request>
which is denied. And finally:
Seitz & Rissanen Expires April 6, 2008 [Page 34]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Request>
02 ...
03 <Attributes Category="&Resource;">
04 <Attribute AttributeId="&resource-id;">
05 <AttributeValue DataType="&xpath;>
06 <xpath>/top[1]/interfaces[2]/interface[1]/name[1]</xpath>
07 </AttributeValue>
08 </Attribute>
09 ...
10 </Request>
which is also denied. The NETCONF response after access control will
therefore like this:
01 <rpc-reply message-id="101"
02 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
03 <data>
04 <top>
05 <interfaces>
06 <name>Ethernet</name>
07 <interface>
08 <name>Ethernet0/0</name>
09 <mtu>1500</mtu>
10 </interface>
11 <interface>
12 <name>Ehternet1/1</name>
13 <mtu>3000</mtu>
14 </interface>
15 <interface>
16 <name>Ethernet2/2</name>
17 <mtu>1000</mtu>
18 </interface>
19 </interfaces>
20 </top>
21 </data>
22 </rpc-reply>
B.2. edit-config example
Given the following edit-config RPC:
Seitz & Rissanen Expires April 6, 2008 [Page 35]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <rpc message-id="101"
02 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
03 <edit-config>
04 <target><running/></target>
05 <config>
06 <top>
07 <interfaces>
08 <name>Ethernet</name>
09 <interface operation="replace">
10 <name>Ethernet0/0</name>
11 <mtu>1500</mtu>
12 <ipAddress operation="create">192.0.0.1</ipAddress>
13 </interface>
14 <interface operation="replace">
15 <name>Ethernet1/1</name>
16 <mtu>3000</mtu>
17 </interface>
18 <interface>
19 <name>Ethernet2/2</name>
20 <mtu operation="replace">1000</mtu>
21 </interface>
22 </interfaces>
23 <interfaces>
24 <name>WLAN</name>
25 <interface operation="delete">
26 <name>WLAN0/0</name>
27 </interface>
28 </interfaces>
29 </top>
30 </config>
31 </edit-config>
32 </rpc>
and the following XACML policy (omitting the subject part):
Seitz & Rissanen Expires April 6, 2008 [Page 36]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Policy PolicyId="ex9" RuleCombiningAlgId="&permit-overrides;">
02 <Target>
03 ...
04 <AnyOf>
05 <AllOf>
06 <Match MatchId="xacml-netconf:function:xpath-node-match">
07 <AttributeValue DataType="&xpath;">
08 <xpath>/top/interfaces[name="Ethernet"]</xpath>
09 </AttributeValue>
10 <AttributeDesignator Category="&Resource;"
11 AttributeId="&resource-id;"
12 DataType="&xpath;"/>
13 </Match>
14 <Match MatchId="&string-equal;">
15 <AttributeValue
16 DataType="&string;">running</AttributeValue>
17 <AttributeDesignator Category="&Resource;"
18 AttributeId="xacml-netconf:attribute:rpc-target"
19 DataType="&string;"/>
20 </Match>
21 </AllOf>
22 </AnyOf>
23 <AnyOf>
24 <AllOf>
25 <Match MatchId="&string-equal;">
26 <AttributeValue
27 DataType="&string;">write</AttributeValue>
28 <AttributeDesignator Category="Action"
29 AttributeId="action-id"
30 DataType="&string;"/>
31 </Match>
32 </AllOf>
33 </AnyOf>
34 </Target>
35 <Rule RuleId="PermitRule" Effect="Permit"/>
36 </Policy>
we generate the following request from the RPC:
Seitz & Rissanen Expires April 6, 2008 [Page 37]
Internet-Draft NETCONF access control profile for XACML October 2007
01 <Request xmlns="urn:oasis:names:tc:xacml:3.0:schema:os">
02 <Attributes Category="&Resource;">
03 <Attribute AttributeId="xacml-netconf:attribute:rpc-target">
04 <AttributeValue DataType="&string;">running</AttributeValue>
05 </Attribute>
06 <Attribute AttributeId="&scope;">
07 <AttributeValue
08 DataType="&string;">XPath-expression</AttributeValue>
09 </Attribute>
10 <Attribute AttributeId="&resource-id;" includeInResult="true">
11 <AttributeValue DataType="&xpath;>
12 <xpath>//*[@operation
13 and not(ancestor::*[@operation])]</xpath>
14 </AttributeValue>
15 </Attribute>
16 </Attributes>
17 <Attributes Category="Action">
18 <Attribute AttributeId="action-id">
19 <AttributeValue DataType="&string;">write</AttributeValue>
20 </Attribute>
21 </Attributes>
22 <Content>
23 <top> [Contents of the <top> element in the RPC] </top>
24 </Content>
25 </Request>
which results in the following XACML response:
01 <Response xmlns="urn:oasis:names:tc:xacml:3.0:schema:os">
02 <Result>
03 <Decision>Permit</Decision>
04 <Attributes Category="&resource;">
05 <Attribute AttributeId="&resource-id;"
06 includeInResult="true">
07 <AttributeValue DataType="&xpath;">
08 <xpath>/top[1]/interfaces[1]/interface[1]</xpath>
09 </AttributeValue>
10 </Attribute>
11 </Attributes>
12 <Status>
13 <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
14 </Status>
15 </Result>
16 <Result>
17 <Decision>NotApplicable</Decision>
18 <Attributes Category="&resource;">
19 <Attribute AttributeId="&resource-id;"
20 includeInResult="true">
Seitz & Rissanen Expires April 6, 2008 [Page 38]
Internet-Draft NETCONF access control profile for XACML October 2007
21 <AttributeValue DataType="&xpath;>
22 <xpath>/top[1]/interfaces[2]/interface[1]</xpath>
23 </AttributeValue>
24 </Attribute>
25 </Attributes>
26 <Status>
27 <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
28 </Status>
29 </Result>
30 <Result>
31 <Decision>Permit</Decision>
32 <Attributes Category="&resource;">
33 <Attribute AttributeId="&resource-id;"
34 includeInResult="true">
35 <AttributeValue DataType="&xpath;">
36 <xpath>/top[1]/interfaces[1]/interface[2]</xpath>
37 </AttributeValue>
38 </Attribute>
39 </Attributes>
40 <Status>
41 <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
42 </Status>
43 </Result>
44 <Result>
45 <Decision>Permit</Decision>
46 <Attributes Category="&resource;">
47 <Attribute AttributeId="&resource-id;"
48 includeInResult="true">
49 <AttributeValue DataType="&xpath;">
50 <xpath>/top[1]/interfaces[1]/interface[3]/mtu[1]</xpath>
47 </AttributeValue>
48 </Attribute>
49 </Attributes>
50 <Status>
51 <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
52 </Status>
53 </Result>
54 </Response>
The meaning of this response is the following:
o The operation on line 09 of the RPC is permitted (lines 02-14 of
the response).
o There is no applicable policy for the operation on line 25 of the
RPC (lines 15-27 of the response). This usually means that we
deny the operation and therefore reject the whole RPC.
Seitz & Rissanen Expires April 6, 2008 [Page 39]
Internet-Draft NETCONF access control profile for XACML October 2007
o The operation on line 14 of the RPC is permitted (line 28-40 of
the response).
o The operation on line 20 of the RPC is permitted (line 41-53 of
the response).
The operation on line 12 of the RPC is not submitted to access
control since a ancestor xml-element already contained a edit-config
operation (line 09). Since we simplify all edit-config operations to
'write', the operation on line 12 would have been permitted anyway as
the ancestor operation was permitted. If the ancestor operation had
been denied the whole RPC would be rejected anyway.
Seitz & Rissanen Expires April 6, 2008 [Page 40]
Internet-Draft NETCONF access control profile for XACML October 2007
Authors' Addresses
Ludwig Seitz
SICS, Swedish Institute of Computer Science AB
Box 1263
Kista 164 29
Sweden
Phone: +46 8 633 1516
Email: ludwig@sics.se
Erik Rissanen
Axiomatics AB
Ringstedsgatan 36
Kista 164 48
Sweden
Email: erik@axiomatics.com
Seitz & Rissanen Expires April 6, 2008 [Page 41]
Internet-Draft NETCONF access control profile for XACML October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Seitz & Rissanen Expires April 6, 2008 [Page 42]