Network Working Group L. Seitz Internet-Draft SICS, Swedish Institute of Intended status: Standards Track Computer Science AB Expires: December 27, 2007 E. Rissanen Axiomatics AB June 25, 2007 NETCONF access control profile for XACML draft-seitz-netconf-xacml-00.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 December 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Seitz & Rissanen Expires December 27, 2007 [Page 1] Internet-Draft NETCONF access control profile for XACML June 2007 Abstract The NETCONF remote network configuration protocol currently lacks an access control model. The need for such a model has be recognized 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 . . . . . . . . . . . . . . . . . . . . . . . 6 5. Policy and Request profile for XACML . . . . . . . . . . . . . 7 5.1. Abbreviations and namespaces . . . . . . . . . . . . . . . 7 5.2. New XACML functions, attributes and datatypes . . . . . . 7 5.3. get and get-config RPC . . . . . . . . . . . . . . . . . . 8 5.4. edit-config RPC . . . . . . . . . . . . . . . . . . . . . 11 5.5. copy-config and delete-config RPC . . . . . . . . . . . . 14 5.6. lock and unlock RPC . . . . . . . . . . . . . . . . . . . 17 5.7. kill-session RPC . . . . . . . . . . . . . . . . . . . . . 19 5.8. close-session RPC . . . . . . . . . . . . . . . . . . . . 20 6. Consequences for NETCONF RPC processing . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Abbreviations . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Seitz & Rissanen Expires December 27, 2007 [Page 2] Internet-Draft NETCONF access control profile for XACML June 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 December 27, 2007 [Page 3] Internet-Draft NETCONF access control profile for XACML June 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 December 27, 2007 [Page 4] Internet-Draft NETCONF access control profile for XACML June 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] 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. Seitz & Rissanen Expires December 27, 2007 [Page 5] Internet-Draft NETCONF access control profile for XACML June 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 allows to get specific parts of a specific configuration. o allows to edit specific parts of a specific configuration. o allows to overwrite a specific configuration with a new one from a specific source. o allows to delete a specific configuration. o allows to lock a specific configuration for editing. o allows to unlock a specific configuration. o allow to get specific parts from the "running" configuration. o allows to close your own session. o 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 operation. Seitz & Rissanen Expires December 27, 2007 [Page 6] Internet-Draft NETCONF access control profile for XACML June 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. 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 datatypes 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 node in a xml-document is matched by a certain XPath [XPath]. Due to the difficulty of encoding a node in its document context, we use a second XPath to point to that node in the document. This function works in two steps. First it evaluates the second Seitz & Rissanen Expires December 27, 2007 [Page 7] Internet-Draft NETCONF access control profile for XACML June 2007 xpath (representing the node) against the Content element of the Request. This XPath must match a single 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 nodes contains the node that results from the first step or one of its ancestors, the value of this function is true, otherwise it is false. 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: //ns1:top/ns1:interfaces[ns1:name="Ethernet"] 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 Seitz & Rissanen Expires December 27, 2007 [Page 8] Internet-Draft NETCONF access control profile for XACML June 2007 behaviour in such a case is to prune the results that are not covered by the users rights. Therefore this profile RECOMMENDS 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 nodes of the data model are the results of the RPC. For each node in the result, run an XACML request. The request contains 1. The whole result document under the node. 2. A "&Resource;" category attribute with AttributeId=&resource-id; having the AttributeValue of DataType="&xpath;" which contains an XPath that uniquely identifies the 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 node that is permitted by the corresponding request is included in the result together with its ancestors and descendants. Those that are not permitted are not included. 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 element SHOULD contain a match of an AttribueValue 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 separate element of the policy target. Example request: Seitz & Rissanen Expires December 27, 2007 [Page 9] Internet-Draft NETCONF access control profile for XACML June 2007 ... /ns1:top[1]/ns1:interface[1] read Ethernet0/0 1500 Ethernet1/1 1000 Example policy: Seitz & Rissanen Expires December 27, 2007 [Page 10] Internet-Draft NETCONF access control profile for XACML June 2007 ... /ns1:top/ns1:interface running read 5.4. edit-config RPC Requests for edit-config RPCs SHALL be formed as follows: Under the 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 Seitz & Rissanen Expires December 27, 2007 [Page 11] Internet-Draft NETCONF access control profile for XACML June 2007 AttributeValue SHALL be "XPath-expression". 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 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 element SHALL be included in the request under the element. If the RPC contains a element the contents of the RPC element that are added to the request element SHALL be edited to add a xml-attribute "operation" with a value corresponding to the value of the 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 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 node in the data-model you are automatically authorised to write to all its children too. The XPath "//*[@operation and not(ancestor::*[@operation])]" performs this selection. 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 element SHOULD contain a match of an AttribueValue corresponding to the desired RPC target (i.e. "running", "startup" or "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 separate element of the policy target. Example request: Seitz & Rissanen Expires December 27, 2007 [Page 12] Internet-Draft NETCONF access control profile for XACML June 2007 ... write Ethernet0/0 1500 Example policy: Seitz & Rissanen Expires December 27, 2007 [Page 13] Internet-Draft NETCONF access control profile for XACML June 2007 ... /ns1:top/ns1:interface[ns1:name="Ethernet0/0"] running write 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 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 target. In case of copy-config RPCs the request SHALL also include the RPC Seitz & Rissanen Expires December 27, 2007 [Page 14] Internet-Draft NETCONF access control profile for XACML June 2007 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 element, containing a single Attribute with the AttributeId="action-id" having the DataType="&string;" and the AttributeValue of "write". It is RECOMMENDED that a policy designed to apply to a copy-config/ delete-config RPC SHOULD match one or more AttribueValues 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 element under a single element in the policy target. The policy SHOULD also match one or more AttribueValues 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 element under a single element in the policy target. Furthermore the policy SHOULD match the AttributeValue "write" with the DataType="&string;", the AttributeId="action-id" and the Category="Action" in a separate element of the policy target. Example request: Seitz & Rissanen Expires December 27, 2007 [Page 15] Internet-Draft NETCONF access control profile for XACML June 2007 ... write Example policy: Seitz & Rissanen Expires December 27, 2007 [Page 16] Internet-Draft NETCONF access control profile for XACML June 2007 ... running https://user@example.com: passphrase/cfg/new.txt write 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 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 December 27, 2007 [Page 17] Internet-Draft NETCONF access control profile for XACML June 2007 "candidate" corresponding to the RPC operation target. Furthermore the request SHALL include the 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 AttribueValues 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 element under a single 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 elements under a separate element of the policy target. Example request: ... lock Example policy: Seitz & Rissanen Expires December 27, 2007 [Page 18] Internet-Draft NETCONF access control profile for XACML June 2007 ... running lock unlock 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 element, containing a single Attribute with the AttributeId="action-id" having the DataType="& Seitz & Rissanen Expires December 27, 2007 [Page 19] Internet-Draft NETCONF access control profile for XACML June 2007 string;" and the AttributeValue "kill-session". It is RECOMMENDED that a policy 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 element of its Target. Example request: ... kill-session Example policy: ... kill-session 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 December 27, 2007 [Page 20] Internet-Draft NETCONF access control profile for XACML June 2007 6. Consequences for NETCONF RPC processing 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 knowlege. 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 or 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 node selection expression and a new function for XACML equivalent to the "xpath-node-match" Function. Seitz & Rissanen Expires December 27, 2007 [Page 21] Internet-Draft NETCONF access control profile for XACML June 2007 7. Security Considerations Security considerations from the XACML standard [XACML] and from the NETCONF standard [RFC4741] apply. Seitz & Rissanen Expires December 27, 2007 [Page 22] Internet-Draft NETCONF access control profile for XACML June 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", . [XACML_MR] Anne, 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, . [XPath] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, . 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 December 27, 2007 [Page 23] Internet-Draft NETCONF access control profile for XACML June 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 o o o o o o o o Seitz & Rissanen Expires December 27, 2007 [Page 24] Internet-Draft NETCONF access control profile for XACML June 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 December 27, 2007 [Page 25] Internet-Draft NETCONF access control profile for XACML June 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 December 27, 2007 [Page 26]