Network Working Group V. Cridlig Internet-Draft Universite Henri Poincare Nancy 1 Intended status: Standards Track November 15, 2006 Expires: May 19, 2007 NETCONF access control framework draft-cridlig-netconf-rbac-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 May 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Cridlig Expires May 19, 2007 [Page 1] Internet-Draft NETCONF access control framework November 2006 Abstract This document defines a role-based access control framework for the NETCONF configuration protocol. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. General overview . . . . . . . . . . . . . . . . . . . . . 4 2.2. Role-Based Access Control in NETCONF . . . . . . . . . . . 4 3. RBAC-related operations . . . . . . . . . . . . . . . . . . . 6 3.1. Activating a role . . . . . . . . . . . . . . . . . . . . 6 3.2. Deactivating a role . . . . . . . . . . . . . . . . . . . 7 3.3. Role (de)activation typical use case . . . . . . . . . . . 7 4. RBAC policy data model . . . . . . . . . . . . . . . . . . . . 9 4.1. RBAC components definition . . . . . . . . . . . . . . . . 9 4.2. RBAC policy example . . . . . . . . . . . . . . . . . . . 10 4.3. XML schema for RBAC . . . . . . . . . . . . . . . . . . . 12 4.4. Updating the RBAC policy . . . . . . . . . . . . . . . . . 15 5. Consequences on existing operations . . . . . . . . . . . . . 16 5.1. get and get-config operations . . . . . . . . . . . . . . 16 5.2. edit-config operation . . . . . . . . . . . . . . . . . . 16 5.3. copy-config operations . . . . . . . . . . . . . . . . . . 17 5.4. delete-config operations . . . . . . . . . . . . . . . . . 17 6. (SSH, BEEP, SOAP/SSL)-user to RBAC-user mapping . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Normative References . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Cridlig Expires May 19, 2007 [Page 2] Internet-Draft NETCONF access control framework November 2006 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]. Cridlig Expires May 19, 2007 [Page 3] Internet-Draft NETCONF access control framework November 2006 2. Introduction 2.1. General overview The current document defines an access control framework for NETCONF. This framework relies on the Role-Based Access Control (RBAC) model and intends to protect NETCONF manager access to resources. The access control process intentionally removes the underlying protocol options from the decisions. In particular, it does not depend on whether the underlying protocol is BEEP, SSH or SOAP. It assumes that this protocol is secure by especially providing authentication, integrity and confidentiality. This choice was made because it is not reasonable to have one access control policy for each of this protocol and for each of their internal options or security services. Another design choice is that each NETCONF agent stores its own access control policy like in VACM. Consequently, the RBAC policy remains customizable for each NETCONF agent in order to fulfill all requirements and scenarii. A NETCONF agent has one instance of the RBAC policy that applies to all the supported datastores (running, candidate, startup). 2.2. Role-Based Access Control in NETCONF The RBAC model has many advantages over the other access control models. In particular, it is scalable in terms of maintainability even with a huge number of users. RBAC helps to organize the permissions into higher level job functions called roles. As an example in the NETCONF context, a role can be a firewall management role, a security management role, a routing management role. Roles can be specialized in a hierarchy. For example, the security management role can be a senior role of the firewall management role and therefore, inherits the permissions of this junior role (firewall management role). In the context of this document, an RBAC user is a NETCONF manager. The latter can be assigned to one or several roles. RBAC is fairly well adapted to Netconf because it includes the concept of session, within which permissions can be activated dynamically. An RBAC session is mapped to a NETCONF session. The NETCONF agent stores an RBAC policy, containing the user, role and permission definitions and their assignements. Cridlig Expires May 19, 2007 [Page 4] Internet-Draft NETCONF access control framework November 2006 Role-Based Access Control model hierarchy ---- | | |----------| |----------| |----------| | User |------| Role |------|Permission| |----------| |----------| |----------| \ / \ / |----------| | Session | |----------| Figure 1 This RBAC policy MAY be stored in an XML file and MAY be part of the agent data model. Therefore the RBAC policy MAY be manageable through NETCONF itself, as it is for VACM in SNMPv3. This allows a large-scale deployement of the access control policy. This document defines a XML-based data model to store the RBAC policy. The specified model and the involved new operations defined in the current document are covered by a new capability: "urn:ietf:params:xml:ns:netconf:rbac:1.0", abbreviated as "#rbac" in the rest of the document. Cridlig Expires May 19, 2007 [Page 5] Internet-Draft NETCONF access control framework November 2006 3. RBAC-related operations In the dynamic RBAC model, roles must be activated at run time. Indeed, the permissions of an RBAC user are not constantly available. An RBAC user has to activate a role to be granted the related permissions. This decreases misconfiguration risks since only a subset of the configuration data is accessible at a given time. However, this subset can be the whole configuration datastore if the role allows it. Two operations are necessary to allow role activation and deactivation. These operations are sent by the manager to the agent and are wrapped into an operation. The operation is a direct child of the NETCONF operation. 3.1. Activating a role Description: Activating a role allows a user to be granted the permissions related to this role in the current NETCONF session. This operation can happen at any time after the hello exchange is done. The manager sends an activate-role operation containing a specified role name to the agent. The agent checks its local RBAC policy to decide whether the user can activate this role or not. In order to activate a role, a user MUST be assigned to this role and the role must be enabled. An enabled role is a role that can be activated. Parameters: Role name: The name of the role to be activated. Positive Response: If the user is assigned to the requested role, and the role is not activated yet in the current session, then the agent sends an containing an element. Negative Response: An element is included within the if the request cannot be completed for any reason. A role activation will fail if the user is not assigned to the requested role, or if the role is already activated or if any other constraint prevents the user from activating the role. Cridlig Expires May 19, 2007 [Page 6] Internet-Draft NETCONF access control framework November 2006 3.2. Deactivating a role Description: Deactivating a role allows a user to revoke the permissions related to this role in the current NETCONF session. This operation can happen at any time after the hello exchange is done. The manager sends a deactivate-role operation containing a specified role name to the agent. The agent checks its local RBAC policy to decide whether the user can deactivate this role or not. Parameters: Role name: The name of the role to deactivate. Positive Response: If the role was activated in the current session, then the agent sends an containing an element. Negative Response: An element is included within the if the request cannot be completed for any reason. A role deactivation will fail if the user had not activate the role previously in the session. 3.3. Role (de)activation typical use case Cridlig Expires May 19, 2007 [Page 7] Internet-Draft NETCONF access control framework November 2006 Role (de)activation process: Manager Agent | | | exchange | |<---------------------------->| | | | | | <(de)activate-role> | |----------------------------->| | | check policy ----------- | |<--------------->| database | | | ----------- |<-----------------------------| | | | | Figure 2 When a NETCONF session is terminated (for example, after a or a ), then all active roles MUST be deactivated within the current session. When a NETCONF session is started (after the hello exchange), then a set of default roles MAY be activated by default on a per-user base, without requiring the operation. This default activation on Netconf session startup saves some messages and avoid the need of a user activity. The set of roles activated by default MAY be chosen by the manager. Cridlig Expires May 19, 2007 [Page 8] Internet-Draft NETCONF access control framework November 2006 4. RBAC policy data model This section defines an XML-based data model representing an RBAC policy. It specifies the main components of RBAC: users, roles and permissions. Sessions are not part of the saved data model, since it is the dynamic part of RBAC. Sessions state (activated and deactivated roles) always remains in memory. 4.1. RBAC components definition The following items list the components of the RBAC model and their internal relationships (assignments): User: A user consists of the following attributes: login: the name of the user. password: the password of the user. public-key: the public key of the user. Role: A role consists of the following attributes: name: the name of the current role. junior-roles: a set of junior roles of the current role. Permission: A permission consists of the following parameters: scope: a representation of the protected resource, typically a MIB name (could be an XPath expression for more granularity). is a child of operation: read (r), write (w) or notify (n). Permission-to-Role Assignement (pra): permRef: reference to a permission. roleRef: reference to a role. User-to-Role Assignement (ura): userRef: reference to a user. roleRef: reference to a role. Cridlig Expires May 19, 2007 [Page 9] Internet-Draft NETCONF access control framework November 2006 4.2. RBAC policy example This example consists of 5 roles. RoutingManager role has read access to the routing configuration. InteriorRoutingManager and ExteriorRoutingManager roles inherit the privileges of RoutingManager. InteriorRoutingManager can also write on OSPF and RIP configurations. ExteriorRoutingManager can write on BGP configuration. SuperRoutingManager inherits all previous roles and can write on all routing configurations. SuperManager has full privileges on all the configuration. RBAC policy example netconf netconf AAAAB3NzaC1yc2E... ...50RfDJ6M= RoutingManager InteriorRoutingManager Cridlig Expires May 19, 2007 [Page 10] Internet-Draft NETCONF access control framework November 2006 ExteriorRoutingManager SuperRoutingManager SuperManager /ycp:netconf/ycp:routing /ycp:netconf/ycp:routing/bgp:bgp /ycp:netconf/ycp:routing/rip:rip /ycp:netconf/ycp:routing/ospf:ospf /ycp:netconf/ycp:routing /ycp:netconf /ycp:netconf/ycp:routing/ospf:ospf Cridlig Expires May 19, 2007 [Page 11] Internet-Draft NETCONF access control framework November 2006 Figure 3 4.3. XML schema for RBAC Here is the XML schema for the RBAC policy. RBAC XML Schema Cridlig Expires May 19, 2007 [Page 12] Internet-Draft NETCONF access control framework November 2006 Cridlig Expires May 19, 2007 [Page 14] Internet-Draft NETCONF access control framework November 2006 Figure 4 4.4. Updating the RBAC policy Whenever an update is done in the RBAC policy, it MUST be immediately applied to the current NETCONF sessions. A user can be removed if and only if it does not appear in any user- to-role assignement. A permission can be removed if and only if it does not appear in any permission-to-role assignement. A role can be removed if and only if it does not appear in any permission-to-role and user-to-role assignement. If a user is removed from the policy, all its current NETCONF sessions must be killed. If a user-to-role assignement is removed from the policy, this role must be deactivated in all sessions belonging to this user where this role is active. If a permission- to-role assignement is removed, the permission MUST be removed from the set of active permissions in all NETCONF sessions having this role or one of its senior role activated. If a permission-to-role assignement is created, the permission must be activated in every session where the related role or one of its senior role is active. Cridlig Expires May 19, 2007 [Page 15] Internet-Draft NETCONF access control framework November 2006 5. Consequences on existing operations The #rbac capability does not require any change to the formats of existing NETCONF operations. However, an additional processing is required on the agent side when it receives some request. In all cases, the agent MUST consider the active roles within the current session. These active roles relate to permissions expressed as a tuple (operation, scope). From the set of active permissions, the agent is able to build the corresponding sets of authorized scopes for read "r" and write "w" operations. Scopes are expressed as XPath expressions. 5.1. get and get-config operations When processing a get or get-config operation, some changes are required due to the RBAC policy enforcement. After or before applying the subtree filtering (or XPath) request to the desired configuration, an additional processing MUST take place to apply the RBAC policy. It consists of selecting the allowed XML nodes and pruning the others depending on the currently active roles. All children and parents of the selected nodes are marked as authorized nodes. While the propagation to the top nodes is necessary to keep the structure of the document, the propagation to the children is a consequence of the subtree-based access control arbitrary choice. It is more scalable to select subtrees rather than individual nodes in the access control policy. Only positive authorizations are allowed in order to avoid conflicts and to constraint the security manager to explicitely give access to resources, all remaining resource being unauthorized by default. All nodes marked as authorized are kept in the XML reply. All other nodes are pruned. 5.2. edit-config operation As for the get/get-config, when a NETCONF manager is authorized to write on an XML node, she is also allowed to modify the whole subtree whose root is this XML node. On receipt of an edit-config request, the agent applies the XPath expressions of the write "w" permissions set on the request. All children and parents of the selected nodes are marked as authorized nodes. If a "replace", "create", "delete", or "merge" operation is set in one of the parents of the selected nodes, access is denied. This requires to set the operation attribute as close as possible to the node to update. Cridlig Expires May 19, 2007 [Page 16] Internet-Draft NETCONF access control framework November 2006 5.3. copy-config operations To perform a copy-config operation, a NETCONF manager MUST have write "w" access on the root node of the configuration datastore. 5.4. delete-config operations To perform a delete-config operation, a NETCONF manager MUST have write "w" access on the root node of the configuration datastore. Cridlig Expires May 19, 2007 [Page 17] Internet-Draft NETCONF access control framework November 2006 6. (SSH, BEEP, SOAP/SSL)-user to RBAC-user mapping The SSH user name is directly mapped to the RBAC user name, whatever is the authentication method (password or public/private key). Cridlig Expires May 19, 2007 [Page 18] Internet-Draft NETCONF access control framework November 2006 7. Security Considerations None. Cridlig Expires May 19, 2007 [Page 19] Internet-Draft NETCONF access control framework November 2006 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Cridlig Expires May 19, 2007 [Page 20] Internet-Draft NETCONF access control framework November 2006 Author's Address Vincent Cridlig Universite Henri Poincare Nancy 1 Email: cridligv@loria.fr Cridlig Expires May 19, 2007 [Page 21] Internet-Draft NETCONF access control framework November 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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). Cridlig Expires May 19, 2007 [Page 22]