Internet Engineering Task Force A. Bierman Internet-Draft netconfcentral.org Intended status: Standards Track August 5, 2007 Expires: February 6, 2008 Network Configuration Extensions : Access Control Model draft-bierman-ncx-acm-00 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 February 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Bierman Expires February 6, 2008 [Page 1] Internet-Draft NCX-ACM August 2007 Abstract The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured data modeling environment which promotes human usability and multi-vendor interoperability. The Network Configuration Extensions (NCX) are a set of specifications intended to address NETCONF data modeling issues. This document defines an Access Control Model (ACM) suitable for use with the NETCONF protocol, intended to promote a more consistent, manageable, and interoperable infra-structure for ongoing development of NETCONF-based management interfaces. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1.1. Requirements Notation . . . . . . . . . . . . . . . . 6 1.1.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . 6 1.1.3. NCX-SMI Terms . . . . . . . . . . . . . . . . . . . . 6 1.1.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 7 1.3. Solution Requirements . . . . . . . . . . . . . . . . . . 8 2. Model Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. External Dependencies . . . . . . . . . . . . . . . . . . 10 2.2. Message Processing Model . . . . . . . . . . . . . . . . . 10 3. Model Components . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Users . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Administrative Roles . . . . . . . . . . . . . . . . . . . 15 3.4. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Security Levels . . . . . . . . . . . . . . . . . . . . . 16 3.6. Access Permissions . . . . . . . . . . . . . . . . . . . . 17 3.6.1. RPC Method Invocation Access . . . . . . . . . . . . . 17 3.6.2. Configuration Data Access . . . . . . . . . . . . . . 17 3.6.3. RPC Response Access . . . . . . . . . . . . . . . . . 19 3.6.4. Notification Access . . . . . . . . . . . . . . . . . 19 3.7. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.7.1. Global Controls . . . . . . . . . . . . . . . . . . . 20 3.7.2. Administrative Role Controls . . . . . . . . . . . . . 20 3.7.3. RPC Operation Access Controls . . . . . . . . . . . . 20 3.7.4. Configuration Data Access Controls . . . . . . . . . . 21 3.7.5. Notification Access Controls . . . . . . . . . . . . . 21 3.8. Access Violation Events . . . . . . . . . . . . . . . . . 21 4. Access Control Procedures . . . . . . . . . . . . . . . . . . 23 4.1. Initial Operation . . . . . . . . . . . . . . . . . . . . 23 4.2. Session Establishment . . . . . . . . . . . . . . . . . . 23 4.3. access-denied Error Handling . . . . . . . . . . . . . . . 24 Bierman Expires February 6, 2008 [Page 2] Internet-Draft NCX-ACM August 2007 4.3.1. access-denied Report for RPC Access . . . . . . . . . 24 4.3.2. access-denied Report for Data Access . . . . . . . . . 25 4.4. Incoming Message Validation . . . . . . . . . . . . . . . 25 4.5. Configuration Database Access Validation . . . . . . . . . 27 4.6. Outgoing Message Validation . . . . . . . . . . . . . . . 28 5. Data Model Definition . . . . . . . . . . . . . . . . . . . . 31 5.1. High Level Procedures . . . . . . . . . . . . . . . . . . 31 5.2. Using Access Control Rules . . . . . . . . . . . . . . . . 31 5.3. Data Organization . . . . . . . . . . . . . . . . . . . . 32 5.4. configCapabilities Object . . . . . . . . . . . . . . . . 33 5.4.1. globalConfig Field . . . . . . . . . . . . . . . . . . 33 5.4.2. groupConfig Field . . . . . . . . . . . . . . . . . . 34 5.4.3. rpcAccessConfig Field . . . . . . . . . . . . . . . . 34 5.4.4. rpcTypeAccessConfig Field . . . . . . . . . . . . . . 34 5.4.5. rpcAccessConfig Field . . . . . . . . . . . . . . . . 34 5.4.6. notificationAccessConfig Field . . . . . . . . . . . . 34 5.4.7. configCapabilities Example . . . . . . . . . . . . . . 34 5.5. profile Object . . . . . . . . . . . . . . . . . . . . . . 35 5.5.1. accessControlMode Field . . . . . . . . . . . . . . . 36 5.5.2. accessDeniedEventEnabled Field . . . . . . . . . . . . 36 5.5.3. profile Example . . . . . . . . . . . . . . . . . . . 36 5.6. groups Object . . . . . . . . . . . . . . . . . . . . . . 37 5.6.1. name Key . . . . . . . . . . . . . . . . . . . . . . . 37 5.6.2. role Field . . . . . . . . . . . . . . . . . . . . . . 38 5.6.3. users Object . . . . . . . . . . . . . . . . . . . . . 38 5.6.4. hosts Object . . . . . . . . . . . . . . . . . . . . . 38 5.6.5. groups Example . . . . . . . . . . . . . . . . . . . . 38 5.7. rpcRules Object . . . . . . . . . . . . . . . . . . . . . 40 5.7.1. ruleNumber Key . . . . . . . . . . . . . . . . . . . . 40 5.7.2. ruleType Field . . . . . . . . . . . . . . . . . . . . 40 5.7.3. groupList Field . . . . . . . . . . . . . . . . . . . 41 5.7.4. rpcTarget Object . . . . . . . . . . . . . . . . . . . 41 5.7.4.1. rpcTypeList Field . . . . . . . . . . . . . . . . 41 5.7.4.2. rpcMethodList Object . . . . . . . . . . . . . . . 41 5.7.4.3. xpathExpr Field . . . . . . . . . . . . . . . . . 41 5.7.4.4. all Field . . . . . . . . . . . . . . . . . . . . 42 5.7.5. rpcRules Example . . . . . . . . . . . . . . . . . . . 42 5.8. dataRules Object . . . . . . . . . . . . . . . . . . . . . 44 5.8.1. ruleNumber Key . . . . . . . . . . . . . . . . . . . . 44 5.8.2. access Field . . . . . . . . . . . . . . . . . . . . . 44 5.8.3. groupList Field . . . . . . . . . . . . . . . . . . . 44 5.8.4. dataTarget Object . . . . . . . . . . . . . . . . . . 44 5.8.4.1. dataNodeList Object . . . . . . . . . . . . . . . 45 5.8.4.2. xpathExpr Field . . . . . . . . . . . . . . . . . 45 5.8.4.3. all Field . . . . . . . . . . . . . . . . . . . . 45 5.8.5. dataRules Example . . . . . . . . . . . . . . . . . . 45 5.9. notificationRules Object . . . . . . . . . . . . . . . . . 48 5.9.1. ruleNumber Key . . . . . . . . . . . . . . . . . . . . 48 Bierman Expires February 6, 2008 [Page 3] Internet-Draft NCX-ACM August 2007 5.9.2. ruleType Field . . . . . . . . . . . . . . . . . . . . 48 5.9.3. groupList Field . . . . . . . . . . . . . . . . . . . 48 5.9.4. eventTarget Object . . . . . . . . . . . . . . . . . . 48 5.9.4.1. eventNodeList Object . . . . . . . . . . . . . . . 49 5.9.4.2. xpathExpr Field . . . . . . . . . . . . . . . . . 49 5.9.4.3. all Field . . . . . . . . . . . . . . . . . . . . 49 5.9.5. notificationRules Example . . . . . . . . . . . . . . 49 5.10. accessDeniedEvent Notification . . . . . . . . . . . . . . 51 5.10.1. eventClass Field . . . . . . . . . . . . . . . . . . . 52 5.10.2. eventSeverity Field . . . . . . . . . . . . . . . . . 52 5.10.3. eventTime Field . . . . . . . . . . . . . . . . . . . 52 5.10.4. eventSessionId Field . . . . . . . . . . . . . . . . . 52 5.10.5. eventSessionAddress Field . . . . . . . . . . . . . . 52 5.10.6. eventGroupName Field . . . . . . . . . . . . . . . . . 52 5.10.7. eventAccessRequested Field . . . . . . . . . . . . . . 52 5.10.8. eventErrorPath Field . . . . . . . . . . . . . . . . . 53 5.10.9. accessDeniedEvent Example . . . . . . . . . . . . . . 53 6. Data Model XSD . . . . . . . . . . . . . . . . . . . . . . . . 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 71 Intellectual Property and Copyright Statements . . . . . . . . . . 72 Bierman Expires February 6, 2008 [Page 4] Internet-Draft NCX-ACM August 2007 1. Introduction The standardization of network configuration interfaces for use with the NETCONF [RFC4741] protocol requires a structured data modeling environment which promotes human usability, and multi-vendor interoperability. This document defines an access control model suitable for use with the NETCONF protocol. The Network Configuration Protocol utilizes the Extensible Markup Language [W3C.REC-xml] for encoding protocol messages used to manage network device configuration databases. However, there is no specification for the inter-operable management of the controlled access to potions of a conceptual NETCONF configuration database. Access control is currently not part of the NETCONF standard, so a NETCONF session is granted access based entirely on the session characteristics in an undocumented proprietary manner, if any access control is available at all. This document discusses the following concepts: o Access Control Model o Access Control Procedures o Access Control Data Model The NETCONF stack can be conceptually partitioned into four layers. Layer Example +-------------+ +--------------------+ +-------------------+ (4) | Content | | Configuration data | | Notification data | +-------------+ +--------------------+ +-------------------+ | | | +-------------+ +-----------------+ +---------------+ (3) | Operations | | | | | +-------------+ +-----------------+ +---------------+ | | | +-------------+ +--------------------+ +----------------+ (2) | RPC | | , | | | +-------------+ +--------------------+ +----------------+ | | | +-------------+ +-----------------------------+ (1) | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ Bierman Expires February 6, 2008 [Page 5] Internet-Draft NCX-ACM August 2007 Figure 1 This document addresses NETCONF protocol access control for the RPC, Operations, and Content layers, as defined in [RFC4741], and [I-D.ietf-netconf-notification]. 1.1. Terminology 1.1.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]. 1.1.2. NETCONF Terms The following terms are defined in RFC 4741 and are not redefined here: o agent o client o manager o operation o RPC o RPC method o server o session o user 1.1.3. NCX-SMI Terms The following terms are defined in the NCX-SMI [I-D.bierman-ncx-smi] and are not redefined here: o application o data model o object Bierman Expires February 6, 2008 [Page 6] Internet-Draft NCX-ACM August 2007 o NETCONF base o NETCONF data model o object identifier o instance identifier 1.1.4. Terms The following terms are used throughout this documentation: access control: A security feature provided by the NETCONF agent, which allows an operator to restrict access to a subset of all NETCONF protocol operations and configuration data, based on various criteria. access control model (ACM): A conceptual model used to configure and monitor the access control procedures desired by the operator to enforce a particular access control policy. access control rule: The conceptual criteria used to determine if a particular NETCONF protocol operation should be permitted or denied. NCX-ACM: The access control model defined in this document. administrative role: The type of administrative role for any session associated with a particular group. This is typically used within an ACM to implicitly enforce a particular set of access control rules, associated with the role. root: The special administrative role, associated with the 'root' user identity for a NETCONF session, with unlimited access, and it is exempt from all access control enforcement. The special user name 'root' is used to identify the this entity on an NCX agent. Also called the 'super-user'. 1.2. Problem Statement Network operators and network equipment (NE) software developers need a lot of expertise, and spend a lot of time, to configure, control, and monitor network devices. Network configuration has traditionally been very proprietary in nature, especially security configuration. By design, the NETCONF protocol specification does not address access control behavior because it is considered to be part of the content layer, and out of Bierman Expires February 6, 2008 [Page 7] Internet-Draft NCX-ACM August 2007 scope. An access control model is needed that is simple to understand, implement, and deploy for the NETCONF protocol, to promote secure and interoperable usage of the NETCONF protocol. The NETCONF protocol uses a procedural interface model, and set of standard protocol operations. There is no standard access control model defined for NETCONF, and a specialized model is needed, which fully secures all mechanisms within the protocol. A standard access control model for the NETCONF protocol will allow a manager to configure and monitor the protocol and data access permissions for any NETCONF session, based on various criteria. Suitable control, monitoring, and notification mechanisms are needed to allow an operator to easily manage all aspects of the ACM behavior. An XML data model, suitable for use with the operation must be available for this purpose. 1.3. Solution Requirements There is a need for a comprehensive access control model for the NETCONF protocol which provides the following features: o An extensible and interoperable conceptual model of the correct access control behavior of a NETCONF agent must be defined. o A data model suitable for use with the and other standard protocol operations is needed to implement the ACM. o For the mandatory transport (SSH), the agent must provide a user identification mechanism, utilizing the user identity provided by the SSH subsystem to the NETCONF agent. o The data model should support the concept of administrative roles, to support the well-established distinction between a root account and other types of (less-privileged) user accounts. o The data model must allow significant access control mechanisms which do not require any Xpath usage. For example, the ability to disable write access, or restrict certain RPC method access such as , must not rely on Xpath. o Access control rules to restrict access to specific sub-trees within the configuration database should be supported. If so, an Xpath expression must be used to identify the sub-tree(s) for this purpose. Bierman Expires February 6, 2008 [Page 8] Internet-Draft NCX-ACM August 2007 o Access control Xpath expressions for configuration data should be restricted to static terms only, such as object identifiers and instance identifiers. These identifiers are defined in the NCX- SMI [I-D.bierman-ncx-smi]. Other static conceptual objects, such as a device type, a physical port number, or a statically allocated MAC or IP address, should also be accepted by the agent. An agent may choose to reject access control rules which represent conceptual objects which are dynamic, such as counters, status objects, and user-supplied description strings. This requirement is needed to reduce the threat of granting access unintentionally due to rapidly changing dynamic terms within the Xpath expression, or usage of complex Xpath expressions that grant more access than intended. Bierman Expires February 6, 2008 [Page 9] Internet-Draft NCX-ACM August 2007 2. Model Overview This section provides a high-level overview of the access control model structure. It describes the NETCONF protocol message processing model, and the conceptual access control requirements within that model. 2.1. External Dependencies The NETCONF [RFC4741] protocol is used for all management purposes within this document. The agent must support the features identified by the 'NETCONF-base' capability. It is expected that the mandatory transport mapping NETCONF Over SSH [RFC4742] is also supported by the agent, and that the agent has access to the user name associated with each session. The XML Path Specification [W3C.xpath] is used within the NETCONF protocol to define filters for configuration data retrieval operations and filters for notification suppression. Support for XPath is optional, and only fully supported if the '#xpath' capability is advertised by the agent. Use of XPath within the data model defined in this document is also optional, based on the '#xpath' capability. The NETCONF Notifications draft [I-D.ietf-netconf-notification] defines notification delivery mechanisms for the NETCONF protocol. An agent must advertise the '#notification' capability for notification delivery to be supported. A notification event type for an access violation event is defined in this document, which may be enabled by the administrator to generate a notification message when an access violation is detected by the agent. The NCX-SMI [I-D.bierman-ncx-smi] specification is used for some data modeling concepts, such as the 'NCX Name' data type, object identifier syntax, and instance identifier syntax. 2.2. Message Processing Model The following diagram shows the NETCONF message flow model, including the points at which access control is applied, during NETCONF message processing. Bierman Expires February 6, 2008 [Page 10] Internet-Draft NCX-ACM August 2007 +-------------------------+ | session | | (role, identity, I/O) | +-------------------------+ | ^ V | +--------------+ +---------------+ | message | | message | | dispatcher | | generator | +--------------+ +---------------+ | ^ ^ V | | +===========+ +-------------+ +----------------+ | |---> | | | | | acc. ctl | | generator | | generator | +===========+ +-------------+ +----------------+ | ^ ^ ^ V +------+ | | +-----------+ | +=============+ +================+ | | | | | | | | processor |-+ | acc. ctl | | access ctl | +-----------+ +=============+ +================+ | | ^ ^ V +----------------+ | | +===========+ | | | | | | | | | acc. ctl | -----------+ | | | +===========+ | | | | | | | | | V V V | | +---------------+ +-----------------+ | configuration | ---> | agent | | database | | instrumentation | | | <--- | | +---------------+ +-----------------+ Figure 2 The follow sequence of conceptual processing steps is executed for each received message: o Access control is applied to all messages received by the agent, individually, for each active session, unless the administrative role for the session is 'root', or the field within the object is set to 'off'. Bierman Expires February 6, 2008 [Page 11] Internet-Draft NCX-ACM August 2007 o A session is bound to an administrative role and a group identity for the lifetime of the session. o An incoming message is dispatched, based on its namespace and element name. o Incoming requests are received by the RPC access control enforcer. o If the session is authorized to execute the RPC method, then processing continues, otherwise the following steps are taken by the agent: 1. If the agent is configured to generate the 'accessDeniedEvent' notification, then one is generated for this access violation event. The field in the notification is set to 'rpcRequest'. 2. The RPC request is rejected with an 'access-denied' error. o If access is granted, the incoming RPC request is processed. o If the configuration database is accessed by the RPC method, then the configuration access control enforcer must authorize the requested operation. o If the requested access is some sort of read operation, and the field within the object is set to 'loose', then configuration data access control enforcement is skipped. o If the session is authorized to perform the requested operation on the requested data, then processing continues, otherwise the following steps are taken by the agent: 1. If the agent is configured to generate the 'accessDeniedEvent' notification, then one is generated for this access violation event. The field in the notification is set to 'dataRead' or 'dataWrite', depending on the nature of the requested configuration database operation. 2. The RPC request is rejected with an 'access-denied' error. o If the field within the object is set to 'loose', then RPC reply access control enforcement is skipped. Otherwise, the RPC reply access control enforcer checks the element (if it exists) within the conceptual reply. It will then prune any data for which the session is not authorized Bierman Expires February 6, 2008 [Page 12] Internet-Draft NCX-ACM August 2007 to read. There is no additional configuration for this enforcement. o The agent should verify that no restricted data (as configured for the configuration database) is contained in the RPC reply. This is especially important for non-standard RPC methods which may return data without properly accessing the configuration database. o The is generated and sent to the manager. The follow sequence of conceptual processing steps is executed for each generated event notification: o Agent instrumentation generates a conceptual notification, for a particular session. o If the field within the object is set to 'loose', then notification access control enforcement is skipped, otherwise, processing continues. o The notification access control enforcer checks the notification, and if it contains any data for which the session is not authorized to read, then the notification with the access violation is dropped for that session only. o If there is no access violation, then the element is generated and sent to the manager. Bierman Expires February 6, 2008 [Page 13] Internet-Draft NCX-ACM August 2007 3. Model Components This section defines the conceptual components related to access control model. 3.1. Users A 'user' is the conceptual identity, which is associated with the access permissions granted to a particular session. A user is identified by an NCX Name string, defined in NCX-SMI, which must be unique within the agent. The user name string is usually derived from the transport layer during session establishment. An agent is required to have an authenticated user name for a session before requests will be accepted. Otherwise all requests must be rejected with an 'access- denied' error-tag value. If groups are not supported by an agent (in the data model), then the user name will be used to automatically create a group with the same group name. An agent may choose not to provide NETCONF-based configuration of the users permitted access to the system, via RPC method or configuration database access. 3.2. Groups Access to a specific NETCONF protocol mechanism is granted to a session, associated with a group, not a user. A group is identified by its group name, which is an NCX Name string. All group names must be unique within the agent. A group member can be identified by either a user name (NCX Name), or an Internet Address (InetAddress). An agent may choose not to support Internet Addresses as group members however. An agent may choose not to fully support groups. At a minimum, all groups will be created by the agent, and there will be one group corresponding to each user, using the same name. An agent may choose not to support user configuration of the groups used within the system. In this case, the groups are configured in some manner outside the scope of this document. Bierman Expires February 6, 2008 [Page 14] Internet-Draft NCX-ACM August 2007 3.3. Administrative Roles An administrative role identifies the type of network operations activity that is expected and permitted for a sessions associated with a particular group. An administrative role is identified by a fixed-value string. There should be very few roles used within a system, in order to reduce complexity. Each group definition within the agent must be associated with a single administrative role, which should not be changed while any sessions associated with that group are active. The following administrative roles are defined within the access control model: root: The 'root' role, associated with the NETCONF session, is given unlimited access permissions. It is exempt from all access control enforcement. admin: The 'admin' role, associated with the NETCONF session, is given specific access permissions, as configured in the agent. It is subject to all access control enforcement. guest: The optional 'guest' role, associated with the NETCONF session, is given limited access permissions, as configured in the agent. It is subject to all access control enforcement, and must not be given any write access to any configuration database. The agent should support a 'root' administrative role, and the user name for this identity should be named 'root'. This role (and user identity) should be built into the agent and not be configurable on the device. The agent must support the 'admin' session role, besides the 'root' role, which is subject to all access control enforcement. The agent may choose to support additional types administrative roles, besides the 'admin' role, which are subject to all access control enforcement. The agent may choose to support the 'guest' role, which is subject to all access control enforcement, and never allowed to write to any configuration data. Bierman Expires February 6, 2008 [Page 15] Internet-Draft NCX-ACM August 2007 3.4. Sessions A session is simply a NETCONF session, which is the entity which is granted access to specific NETCONF protocol mechanisms. A session is always associated with a specific administrative role, for the lifetime of the session. A session is associated with a single group name for the lifetime of the session. (The user name may be the group name in some cases). It will be used during all access control rule evaluation procedures, performed by the agent. 3.5. Security Levels There are four security levels built into the access control model, which affect the way the agent will behave. These security levels will override individual access control rules configured on the system. They are used to assist in access control deployment and debugging, and provide a simple mechanism to configure common security profiles with a single data model object. An agent should support the following security levels: off: All access control is disabled. warn: All access control is checked, but instead of enforcing an access control rule, the agent will generate a log entry and/or an event notification, and allow the requested operation to proceed. loose: During configuration database access control enforcement, only write access is checked. strict: During configuration database access control enforcement, all access is checked. An agent implementer must choose a default security level that is in effect when the device is shipped. It is suggested that the 'loose' or 'strict' security level be selected as the default. An agent should require that the 'root' session role be used in order to modify the global security level. Once access control configuration has been tested and fully functional, an administrator should change the security level to 'strict', and operate in this mode during normal network operations. Bierman Expires February 6, 2008 [Page 16] Internet-Draft NCX-ACM August 2007 3.6. Access Permissions The access permissions are the NETCONF protocol specific set of permissions that have been assigned to a particular session role or group. The same access permissions should stay in affect for the lifetime of a session. The access control model treats RPC method execution separately from configuration database access and outgoing messages: 1. Permission to invoke the request. 2. Permission to access the configuration database. 3. Permission to send the response or message. 3.6.1. RPC Method Invocation Access Permission to invoke an RPC method is treated separately from all other access mechanisms, within the access control model and the data model. Instead of multiple types of access, an access control rule for controlling RPC method access uses a simple boolean, determining whether permission to invoke the RPC method is granted or not. 3.6.2. Configuration Data Access There are three access permissions associated with configuration database data structures that are defined. These coincide with the SMIv2 [RFC2578] MAX-ACCESS clause values in name and concept. They also support the 'operation' attribute used with the protocol operation, which makes a clear distinction between create and merge operations. The following fixed access permissions apply only to configuration data. These permissions are associated statically via the data model definition (e.g., MAX-ACCESS clause) or dynamically via an access control configuration data model. none: * No access is permitted at all. read-only: * Configuration database retrieval operations are permitted. Bierman Expires February 6, 2008 [Page 17] Internet-Draft NCX-ACM August 2007 * Notification generation is permitted. read-write: * Configuration database edit operations are permitted. * Configuration database retrieval operations are permitted. * Notification generation is permitted. read-create: * Configuration database create operations are permitted. * Configuration database delete operations are permitted. * Configuration database edit operations are permitted. * Configuration database retrieval operations are permitted. * Notification generation is permitted. These permissions need to be explicitly mapped to the NETCONF operation attribute, used in the protocol operation. The 'read-only' access permission does not apply to the 'operation' attribute. If a manager has read-only access to some node in the configuration database, it is possible that is may have higher access for a child node of . This is typically the case if a user- configurable optional object is contained within a fixed node (e.g., within the container). The 'read-write' permission applies to the following operation, and indicates access permission in the following situations: o merge with existing node o replace an existing node The 'read-write' permission can only be granted for writable objects which cannot be created by the manager, either directly, or as a side effect of the protocol operation. In other words, all the nodes (from root to the target nodes) must already exist in the agent for write access to be granted. If an object has a agent-supplied default value, the object is considered to be present, even if the operation does not indicate the object is present, due to suppression of default values. Bierman Expires February 6, 2008 [Page 18] Internet-Draft NCX-ACM August 2007 In this case, write permission is granted as if the object was present with the agent supplied default value. The 'read-create' permission applies to all possible operation attribute situations: o merge o replace o create o delete This write permission can only be granted for writable objects which can be created and deleted by the manager, via direct action within a protocol operation. 3.6.3. RPC Response Access A session must have read access to all contents of the element, if it is present. The agent must prune any data which the session is not authorized to receive. If some object within the data corresponds to an object in the configuration database, then the agent should use the access control configuration for that object to determine if the session should be granted access. If the data does not correspond to objects within the configuration database, then the agent should use mechanisms (outside the scope of this document) to determine if read access should be granted. 3.6.4. Notification Access A session must have read access to all contents of the element, if any data is present. The agent must drop the notification (for that session only) if it contains any data which the session is not authorized to receive. If an access control rules exist, which pertain to the namespace URI and/or notification event type element, then access must denied if the rules indicate the group is not authorized to receive that notification event type. If the session is authorized to receive the event type, it must also be authorized to receive any data within the notification as well. If some object within the data corresponds to an object in the configuration database, then the agent should use the access control Bierman Expires February 6, 2008 [Page 19] Internet-Draft NCX-ACM August 2007 configuration for that object to determine if the session should be granted access. If the data does not correspond to objects within the configuration database, then the agent should use mechanisms (outside the scope of this document) to determine if access should be granted. 3.7. Controls 3.7.1. Global Controls An agent may choose to allow a manager to configure the global security level used to control the overall operation of the access control system. If so, then the 'root' administrative role should be required to modify this parameter. If notifications are supported then a manager should be able to configure whether or not the 'accessDeniedEvent' notification should be generated. If so, then the 'root' administrative role should be required to modify this parameter. An agent may choose to allow a manager to configure the groups used to control which user names or InetAddresses (associated with each session) should be given access to the system.. If so, then the 'root' administrative role should be required to modify this configuration data. 3.7.2. Administrative Role Controls The administrative role assigned to a group can be used to control course-grained access to configuration data, e.g., no restrictions for 'root', or no write access for 'guest'. The administrative role is associated with a group within the data model in Section 5. 3.7.3. RPC Operation Access Controls A manager can specify the scope of the access control rule for an RPC method in four ways: 1. for all RPC methods defined with the specified RPC method type(s), as defined in NCX-SMI (e.g., 'config', 'monitor', 'exec', 'debug'). 2. for all RPC methods defined within a specific namespace. 3. for one RPC method defined within a specific namespace. Bierman Expires February 6, 2008 [Page 20] Internet-Draft NCX-ACM August 2007 4. for all RPC methods indicated by a particular boolean Xpath expression. An agent may choose not to support the RPC method type form of access control rule definition. An agent must support the Xpath expression form of access control rule if it advertises the '#xpath' capability. 3.7.4. Configuration Data Access Controls A manager can specify the scope of the access control rule for a portion of the configuration database in three ways: 1. for all configuration data within a specific namespace 2. for all configuration data within a specific XML sub-tree 3. for all configuration indicated by a particular node set Xpath expression. An agent must support the Xpath expression form of access control rule if it advertises the '#xpath' capability. 3.7.5. Notification Access Controls A manager can specify the scope of the access control rule for a notification in three ways: 1. for all notification event types within a specific namespace 2. for a specific event types within a specific namespace 3. for all notification content indicated by a particular boolean Xpath expression. The 'event type' corresponds to the one and only child node of the element. The namespace URI and element name for this node are used to define the notification type. An agent must support the Xpath expression form of access control rule if it advertises the '#xpath' capability. 3.8. Access Violation Events If the agent supports the '#notification' capability, then it should support generation of the 'accessDeniedEvent' notification type, defined within the data model. Bierman Expires February 6, 2008 [Page 21] Internet-Draft NCX-ACM August 2007 The 'accessDeniedEvent' event type is controlled by a global parameter, used to enable or disable notification generation for this event type. If generation of the notification is enabled, and the global security level is not 'off', then one notification is generated for each received message that contains any access violations. Logging and delivery of this notification are outside the scope of this document. Bierman Expires February 6, 2008 [Page 22] Internet-Draft NCX-ACM August 2007 4. Access Control Procedures NCX access control procedures (within the NETCONF agent) are specific to the NETCONF message processing model, and are based on the specific vulnerabilities that can occur during each type of message processing procedure. All aspects of data access via NETCONF protocol behavior, including side effects from operations, and external protocols (such as SNMP or SSH/CLI), are considered within the responsibility of the NETCONF agent to secure against unauthorized access. There are six separate phases that must be addressed, three of which are related to the NETCONF message processing model. In addition, the initial start-up mode for an NCX agent, session establishment, and 'access-denied' error handling must also be considered. 4.1. Initial Operation Upon the very first start-up of the NCX agent, the access control configuration will probably not be present. If not, an agent should not allow any write access to any session role except 'root' in this state. If the configured (or default) access control profile is 'strict', then the agent must not allow any write access to any session role except 'root' in this state. If the configured (or default) access control profile is 'strict', then the agent must not allow any read access to any session role except 'root' in this state. The agent should prompt or alert the operator somehow until the access control configuration has been set. This initial configuration mode continues until the agent deems that the access control configuration has been set.. 4.2. Session Establishment The access control model applies specifically to the well-formed XML content transferred between a manager and an agent, after session establishment has been completed, and after the exchange has been successfully completed. An agent must not include any sensitive information in any elements within the exchange. Once session establishment is completed, and a user identity has been Bierman Expires February 6, 2008 [Page 23] Internet-Draft NCX-ACM August 2007 authenticated, a NETCONF agent will enforce the access control rules, based on the supplied user identity and the configuration data stored on the agent. 4.3. access-denied Error Handling The 'access-denied' error report is generated when the access control system denies access to either a request to invoke an RPC method or a request to perform a particular operation on the configuration database. An agent must not include any sensitive information in any elements within the response. If the field within the object is equal to 'warn', then the agent may choose to generate 'access-denied' warning reports, in addition to generating an 'accessDeniedEvent' notification (if supported). In this case, the field is set to 'warning' instead of 'error'. 4.3.1. access-denied Report for RPC Access If permission to invoke an RPC method is not granted, the following element is sent within the RPC response. The following example shows an 'access-denied' error report that might be returned if access to the operation is denied. rpc access-denied error /rpc/edit-config Access to RPC method denied Figure 3 Bierman Expires February 6, 2008 [Page 24] Internet-Draft NCX-ACM August 2007 4.3.2. access-denied Report for Data Access If permission to invoke the requested protocol operation (e.g., read, write, create/delete) is not granted for the specified configuration data, the following element is sent within the RPC response. The following example shows an 'access-denied' error report that might be returned if some access to the interface named 'eth1' is denied. application access-denied error /rpc/edit-config/config/ex:interfaces/ex:interface[ex:name='eth1'] Access to configuration data denied Figure 4 4.4. Incoming Message Validation The diagram below shows the basic conceptual structure of the access control processing model for incoming NETCONF messages, within an agent. Bierman Expires February 6, 2008 [Page 25] Internet-Draft NCX-ACM August 2007 NETCONF agent +------------+ | XML | | message | | dispatcher | +------------+ | | +-----------+-----------+ V V +-------------+ +------------+ | acme NS | | NC-base NS | | | | | +-------------+ +------------+ | | | | | | | +---------------+ +-----+ +--------+ | | V V V V +-----------+ +---------------+ +------------+ | acme NS | | NC-base NS | | NC-base NS | | | | | | | +-----------+ +---------------+ +------------+ | | | | +-----+ | V V V +----------------------+ | | | configuration | | database | +----------------------+ Figure 5 Access control begins with the message dispatcher. Only well-formed XML messages should be processed by the access control system. An agent should not allow access to configuration databases through any top level element except the element in the NETCONF-base namespace. If it does, (e.g., ) the agent should still enforce access control to configuration data, even if the access is from some mechanism outside the standard protocol operations. After the agent validates the element, and determines the namespace URI and the element name of the RPC method being requested, the RPC access control enforcer verifies that the session is authorized to invoke the RPC method. Bierman Expires February 6, 2008 [Page 26] Internet-Draft NCX-ACM August 2007 If the session is not authorized to invoke the RPC method with the given set of parameters, then an is generated with the following information: error-tag: access-denied error-path: /rpc/method-QName, where 'method-QName' is a qualified name identifying the actual RPC method name. For example, '/rpc/ edit-config' represents the operation in the NETCONF base namespace.. If the configuration database is accessed, either directly or as a side effect of the RPC operation, then the configuration database access enforcer must intercept the operation and make sure the session is authorized to perform the requested operation on the specified data. If an 'access-denied' error is generated at this point, then no information related to any parameters within the request should be returned in the response. A element must not be included in the response. Only the name of the RPC method should be returned in element or the element. The should not reveal any additional information about the access violation. 4.5. Configuration Database Access Validation An agent must ensure that all access to the data within the configuration database is authorized, no matter which RPC method, top-level construct other than , or even other protocol than NETCONF, is used to access the database. For access control purposes, there is only one conceptual configuration database. The same access control rules are used for all configuration database instances, such as the or configurations. Access to configuration data is controlled by assigning a access control rule to a specific sub-tree in the database, for a conceptual object, using the { group-name, max-access, object-identifier } values for the sub-tree to be restricted. Access to configuration data can also be controlled by assigning a access control rule to a specific namespace URI in the database, for all conceptual objects defined within the namespace, using the { group-name, max-access, namespace-URI } values for the namespace to be restricted. Bierman Expires February 6, 2008 [Page 27] Internet-Draft NCX-ACM August 2007 If the '#xpath' capability is advertised by the agent, then an Xpath expression can be used to specify the configuration data sub-tree(s) associates with an access control rule. NETCONF agent +------------------------------+ | NETCONF | | configuration | | database | +------------------------------+ | | | V V V +------------+ +------------+ +-------------+ | NC-base NS | | NCX-SEC NS | | foo-elem NS | | | | | | | | app hdr | | app hdr | | element | +------------+ +------------+ +-------------+ | \ +---------------+ \ V V V +----------------+ +-----------+ +------------+ | NC-notif NS | | NC-mon NS | | NCX-ACM NS | | | | | | | | object | | object | | object | +----------------+ +-----------+ +------------+ | +------------------------+----------------------+ V V V {Additional layers, e.g., child nodes and nested objects) Figure 6 4.6. Outgoing Message Validation There are two outbound message types to consider: the and the messages. The message should be checked by the agent to make sure no unauthorized data is contained within it. If so, the restricted data must be removed from the message before it is sent to the manager. Configuration of access control rules exclusively for Bierman Expires February 6, 2008 [Page 28] Internet-Draft NCX-ACM August 2007 messages is outside the scope of this document. It is suggested that the is used for this purpose. The message should be checked by the agent to make sure no unauthorized data is contained within it. If so, the entire notification is dropped for that session. The object is used to configure access control rules for notification messages. The following figure shows the conceptual message processing model for outgoing messages. Bierman Expires February 6, 2008 [Page 29] Internet-Draft NCX-ACM August 2007 NETCONF agent +------------+ | XML | | message | | generator | +------------+ ^ | +-----------+-------------+ | | +-------------+ +----------------+ | | | | | generator | | generator | +-------------+ +----------------+ ^ ^ | | +=============+ +=================+ | | | | | acc. ctl. | | access control | | | | | +=============+ +=================+ ^ ^ | | \ / \ / \ / +-----------------------+ | | | agent instrumentation | | | +-----------------------+ | ^ | | V | +----------------------+ | | | configuration | | database | +----------------------+ Figure 7 Bierman Expires February 6, 2008 [Page 30] Internet-Draft NCX-ACM August 2007 5. Data Model Definition This section defines the semantics of the conceptual data structures found in the data model in Section 6. 5.1. High Level Procedures There are some high level management procedures that an administrator needs to consider before using this access control model: 1. Set the global security level. 2. Enable or disable the notification. 3. Configure (or pre-configure) the object. 4. Configure zero or more access control rules for RPC method invocation control. 5. Configure zero or more access control rules for configuration database access. 6. Configure zero or more access control rules for notification event type access. Notification delivery must be properly configured (outside the scope of this document) in order for the notification to actually be generated. 5.2. Using Access Control Rules There are some important considerations for proper configuration of the access control rules used within the data model. o The start state for allowing access is considered to be undefined. o The agent determines the correct set of access control rules to use, based on the stage of protocol message processing. For example, if is processing an RPC request, then the object is used. o Access control rules are processed by the agent in ascending order, starting with the lowest numbered rule (i.e., lowest value of the ruleNumber key). o The agent determines the target of each rule. If the target defined within the rule includes the target being checked for access permissions, then the rule is considered a match, and the Bierman Expires February 6, 2008 [Page 31] Internet-Draft NCX-ACM August 2007 specific access is either permitted or denied based on that rule. o The special target rule called is used to match anything. It is customary to use this type of rule as the last rule within a sequence of access control rules. For example, in order to deny all access except a few RPC methods, an operator might set up an object with a few rules to permit invocation of certain RPC methods, and the very last rule would be a 'catchall' rule, which denies access to all RPC methods. o If no access rule is found associated with the requested operation, then the agent should consider the access to be denied. However, if the global security level is 'loose', the agent may choose to permit the requested operation instead. 5.3. Data Organization The top-level element is called , and it is defined the 'NCX-security' namespace. The second level container element is named and it is also defined in the NCX-security namespace. There are six groups of parameters defined as child nodes of the element. Each group is defined in detail within this section. The data model also contains a notification event definition for reporting an access control violation. configCapabilities: Indicates access control configuration capabilities of the agent (read-only)" profile: Configures global access control parameters. groups: Configures the groups used within the access control system. rpcRules: Configures the access control rules for RPC method invocation. dataRules: Configures the access control rules for configuration database access. notificationRules: Configures the access control rules for controlling delivery of messages. The following figure shows the XML layering used within the data model. Bierman Expires February 6, 2008 [Page 32] Internet-Draft NCX-ACM August 2007 NETCONF Configuration Database +-----------------+ | netconf-BASE NS | | | +-----------------+ | +-----------------+ +=====================+ | NCX-ACM NS | | NCX-ACM NS | | | | | +-----------------+ | (Notification) | | +=====================+ +-----------------+ | NCX-ACM NS | | | +-----------------+ | +----------------------+ | NCX-ACM NS | | OBJECT NODE | | | | | | | | | | | | | +----------------------+ Figure 8 5.4. configCapabilities Object The is a read-only element, which contains some boolean fields indicating which configuration objects the agent will allow user configuration via the NETCONF protocol. Agent implementation of this entire object is mandatory. 5.4.1. globalConfig Field Boolean indicating whether the agent allows user configuration of the parameters within the object. Bierman Expires February 6, 2008 [Page 33] Internet-Draft NCX-ACM August 2007 5.4.2. groupConfig Field Boolean indicating whether the agent allows user configuration of the parameters within the object. 5.4.3. rpcAccessConfig Field Boolean indicating whether the agent allows user configuration of access control rules within the object. 5.4.4. rpcTypeAccessConfig Field Boolean indicating whether the agent allows user configuration of access control rules bases on the conceptual type of an RPC method (as defined in NCX-SMI). The 'rpcAccessConfig' field must be 'true' if this field is 'true'. 5.4.5. rpcAccessConfig Field Boolean indicating whether the agent allows user configuration of access control rules within the object. 5.4.6. notificationAccessConfig Field Boolean indicating whether the agent allows user configuration of access control rules within the object. 5.4.7. configCapabilities Example The following example shows a operation and response for an example object. Bierman Expires February 6, 2008 [Page 34] Internet-Draft NCX-ACM August 2007 true true true false true false Figure 9 5.5. profile Object The object is a container with some read-write elements, which are enumerated strings indicating the global access control behavior for the agent. Agent implementation of this object is mandatory. Write access is required if the 'globalConfig' field in the object is set to 'true'. However, write access to the 'accessDeniedEventEnabled' field is not required if the '#notification' capability is not supported. Bierman Expires February 6, 2008 [Page 35] Internet-Draft NCX-ACM August 2007 5.5.1. accessControlMode Field Enumerated string indicating the access control security level that should be applied by the agent. off: All access control is disabled. warn: All access control is checked, but instead of enforcing an access control rule, the agent will generate a log entry and/or an event notification, but allow the requested operation to proceed. loose: During configuration database access control enforcement, only write access is checked. strict: During configuration database access control enforcement, all access is checked. 5.5.2. accessDeniedEventEnabled Field Boolean indicating whether the agent should generate the notification when access violations are detected. 5.5.3. profile Example The following example shows a operation and response for an example object. Bierman Expires February 6, 2008 [Page 36] Internet-Draft NCX-ACM August 2007 strict true Figure 10 5.6. groups Object The object is a container with one or more instances of the object within it. Each element instance is indexed by the value of its 'name' field. Agent implementation of this object is mandatory. Write access is required if the 'groupConfig' field in the object is set to 'true'. 5.6.1. name Key NCX Name string identifying the name of the group. This value must be unique for all instances of the element. Bierman Expires February 6, 2008 [Page 37] Internet-Draft NCX-ACM August 2007 5.6.2. role Field String defining the administrative role assigned to this group. This field should not be changed once the group is created. 5.6.3. users Object Table of user name strings which are considered to be part of the group. This nested object is optional to use. If not used, then the object may be used instead. This object is a container, which contains indexed and ordered entries. It should contain one or more elements. Each one contains an NCX Name string, which must be unique for all instances of the element. 5.6.4. hosts Object Table of InetAddress strings which represent management station addressed, which are considered to be part of the group. This nested object is optional to use. If not used, then the object may be used instead. This object is a container, which contains indexed and ordered entries. It should contain one or more elements. Each one contains an InetAddress string, which must be unique for all instances of the element. 5.6.5. groups Example The following example shows a operation and response for an example object. Bierman Expires February 6, 2008 [Page 38] Internet-Draft NCX-ACM August 2007 superuser root root routers admin fred support admin fred barney wilma 192.168.1.1 interns guest bam-bam pebbles Bierman Expires February 6, 2008 [Page 39] Internet-Draft NCX-ACM August 2007 Figure 11 In this example, four groups are defined: o A group called 'superuser', containing the user 'root', using the 'root' administrative role. No access rules are needed for this group, since access control is not applied to the 'root' administrative role. o A group called 'routers', containing the user 'fred', using the 'admin' administrative role. This group is allowed full access to protocol features, depending on the access control rules configured for the system. o A group called 'support', containing three users and one IPv4 address, using the 'admin' administrative role. o A group called 'interns', containing two users, using the 'guest' administrative role. This group does not have any write permissions to any configuration data, regardless of the access control rules configured for the system. 5.7. rpcRules Object The object is a container with one or more instances of the object within it. Each element instance is indexed by the value of its 'ruleNumber' field. If the 'rpcAccessConfig' field in the object is 'true', then the agent supports user creation, modification, and deletion of this object. Agent implementation of this object is mandatory. Write access is required if the 'rpcAccessConfig' field in the object is set to 'true'. 5.7.1. ruleNumber Key A non-negative integer identifying the relative order of this entry among all other instances of the element. This value must be unique for all instances of the element. The agent will evaluate RPC method access rules in ascending order. The 'ruleNumber' values do not have to be contiguous. 5.7.2. ruleType Field Enumerated string defining the type of rule match for this access control rule: Bierman Expires February 6, 2008 [Page 40] Internet-Draft NCX-ACM August 2007 permit: Rule match indicates that access permission is granted. deny: Rule match indicates that access permission is denied. 5.7.3. groupList Field List of one or more group names for which this rule applies. 5.7.4. rpcTarget Object Represents the RPC method targets that are identified by this access control rule. Contains a choice between one object, one object, one object, or one element. 5.7.4.1. rpcTypeList Field If the 'rpcTypeAccessConfig' field in the object, then the agent supports this field. This field represents a list of RPC method types, which are used to match against the type of RPC method being invoked. If the type of the requested RPC method is in the list, then the access control rule is considered a match. 5.7.4.2. rpcMethodList Object This field identifies the RPC methods that are considered part of this access control rule. This nested object contains two fields: namespaceUri: The namespace URI associated with the RPC method(s) identified by this access control rule. elementNames: List of element names of the RPC methods within the indicated namespace that are identified by this access control rule. If this field is absent, then all RPC methods defined in the indicated namespace are identified by this access control rule. 5.7.4.3. xpathExpr Field This field contains a boolean Xpath expression which the agent will use to identify the requested RPC method or parameter data within the RPC method, to match this access control rule. An agent which advertises the '#xpath' capability must support this object. Bierman Expires February 6, 2008 [Page 41] Internet-Draft NCX-ACM August 2007 5.7.4.4. all Field Empty element indicating that the access control rule applies to all RPC methods in all namespaces. 5.7.5. rpcRules Example The following example shows a operation and response for an example object. 1 permit routers urn:ietf:params:xml:ns:netconf:base:1.0 edit-config copy-config delete-config commit discard-changes Bierman Expires February 6, 2008 [Page 42] Internet-Draft NCX-ACM August 2007 4 permit routers support urn:ietf:params:xml:ns:netconf:base:1.0 get-config get validate 6 permit interns urn:ietf:params:xml:ns:netconf:base:1.0 get-config get 99 deny support interns Figure 12 Bierman Expires February 6, 2008 [Page 43] Internet-Draft NCX-ACM August 2007 o Rule '1' allows the 'routers' group permission to invoke the , , , , and protocol operations. o Rule '4' allows the 'routers' and 'support' groups permission to invoke the , , and protocol operations. o Rule '6' allows the 'interns' group permission to invoke the and protocol operations. o Rule '99' denies access to the 'support' and 'interns' groups from invoking any RPC method (not explicitly mentioned in a previous rule). 5.8. dataRules Object The object is a container with one or more instances of the object within it. Each element instance is indexed by the value of its 'ruleNumber' field. Agent implementation of this object is mandatory. If the 'databaseAccessConfig' field in the object is 'true', then the agent supports user creation, modification, and deletion of this object. 5.8.1. ruleNumber Key A non-negative integer identifying the relative order of this entry among all other instances of the element. This value must be unique for all instances of the element. The agent will evaluate configuration data access rules in ascending order. The 'ruleNumber' values do not have to be contiguous. 5.8.2. access Field The level of access permissions associated with this access control rule. This object is encodes as an enumerated string. The values are defined in Section 3.6.2. 5.8.3. groupList Field List of one or more group names for which this rule applies. 5.8.4. dataTarget Object Represents the objects that are identified by this access control rule. Contains a choice between one object, one Bierman Expires February 6, 2008 [Page 44] Internet-Draft NCX-ACM August 2007 object, and one object. 5.8.4.1. dataNodeList Object Contains a list of elements which are used to match against the configuration data elements within the agent, or data within an RPC response or notification message. If the element is identified within the node list, then the access control rule is considered a match. This nested object contains two fields: namespaceUri: The namespace URI associated with the data node(s) identified by this access control rule. elementNames: List of element names of the data nodes within the indicated namespace that are identified by this access control rule. If this field is absent, then all data nodes defined in the indicated namespace are identified by this access control rule. 5.8.4.2. xpathExpr Field This field contains a node set Xpath expression which the agent will use to identify the data nodes which are considered to match this access control rule. An agent which advertises the '#xpath' capability must support this object. 5.8.4.3. all Field Empty element indicating that the access control rule applies to all configuration data in all namespaces. 5.8.5. dataRules Example The following example shows a operation and response for an example object. Bierman Expires February 6, 2008 [Page 45] Internet-Draft NCX-ACM August 2007 1 read-create routers http://netconfcentral.org/ncx/security 3 read-create routers /ex:routers/ex:config 4 read-only support http://netconfcentral.org/ncx/security 7 Bierman Expires February 6, 2008 [Page 46] Internet-Draft NCX-ACM August 2007 read-write support /ex:interfaces/ex:interface[ex:name='eth0'] 10 none interns http://netconfcentral.org/ncx/security 99 read-only routers support interns Figure 13 o Rule '1' allows the 'routers' group permission to invoke any operation on all data defined within the 'NCX security' namespace. o Rule '3' allows the 'routers' group permission to invoke any operation on the 'config' element within the 'example.com' router data model.. o Rule '4' allows the 'support' group permission to read any data defined in the 'NCX security' namespace. Bierman Expires February 6, 2008 [Page 47] Internet-Draft NCX-ACM August 2007 o Rule '7' allows the 'support' group permission to read and write the interface named 'eth0', (in the example.com Interfaces data model), but not create or delete operations. o Rule '10' denies the 'interns' group permission to read or write any data defined in the 'NCX security' namespace. o Rule '99' permits read access to all the groups to any data not mentioned in a previous rule. 5.9. notificationRules Object The object is a container with one or more instances of the object within it. Each element instance is indexed by the value of its 'ruleNumber' field. Implementation of this object is mandatory. If the 'notificationAccessConfig' field in the object is 'true', then the agent supports user creation, modification, and deletion of this object. 5.9.1. ruleNumber Key A non-negative integer identifying the relative order of this entry among all other instances of the element. This value must be unique for all instances of the element. The agent will evaluate notification data access rules in ascending order. The 'ruleNumber' values do not have to be contiguous. 5.9.2. ruleType Field Enumerated string defining the type of rule match for this access control rule: permit: Rule match indicates that access is granted. deny: Rule match indicates that access is denied. 5.9.3. groupList Field List of one or more group names for which this rule applies. 5.9.4. eventTarget Object Represents the notification event types that are identified by this access control rule. Contains a choice between one Bierman Expires February 6, 2008 [Page 48] Internet-Draft NCX-ACM August 2007 object, one object, and one object. Agent implementation of this object is mandatory. Write access is required if the 'rpcAccessConfig' field in the object is set to 'true'. 5.9.4.1. eventNodeList Object Contains a list of elements which are used to match against the configuration data elements within the agent, or data within an RPC response or notification message. If the element is identified within the node list, then the access control rule is considered a match. This nested object contains two fields: namespaceUri: The namespace URI associated with the notification data node(s) identified by this access control rule. elementNames: List of element names of the notification data nodes within the indicated namespace that are identified by this access control rule. If this field is absent, then all notification data nodes defined in the indicated namespace are identified by this access control rule. 5.9.4.2. xpathExpr Field This field identifies a boolean Xpath expression which the agent will use to identify the notification data nodes which are considered to match this access control rule. An agent which advertises the '#xpath' capability must support this object. 5.9.4.3. all Field Empty element indicating that the access control rule applies to all notification messages in all namespaces. 5.9.5. notificationRules Example The following example shows a operation and response for an example object. Bierman Expires February 6, 2008 [Page 49] Internet-Draft NCX-ACM August 2007 1 permit routers support 2 permit interns urn:ietf:params:xml:ns:netconf:base:1.0 3 deny interns Bierman Expires February 6, 2008 [Page 50] Internet-Draft NCX-ACM August 2007 Figure 14 o Rule '1' permits the 'routers' and 'support' groups to receive all notification messages in all namespaces. o Rule '2' permits the 'interns' group to receive all notification messages in the 'NETCONF base' namespace. o Rule '3' prevents the 'interns' group from receiving any other notification messages in any other namespace. 5.10. accessDeniedEvent Notification The access denied event is generated once for each received message which would have caused one or more potential access violations. If the '#notification' capability is supported by the NETCONF agent, and the 'accessDeniedEventEnabled' field within the object is set to 'true', then the agent will generate notification messages for the event type, as needed. The event type namespace is the NCX-ACM data model target namespace. The event type element name is 'accessDeniedEvent'. This notification message contains eight data elements: o eventClass o eventSeverity o eventTime o eventSessionId o eventSessionAddress o eventGroupName o eventAccessRequested o eventErrorPath Bierman Expires February 6, 2008 [Page 51] Internet-Draft NCX-ACM August 2007 5.10.1. eventClass Field The 'eventClass' field will probably be defined as a standard outside the scope of this document. This field is static, and must contain the string 'security'. 5.10.2. eventSeverity Field The 'eventSeverity' field will be defined as a standard outside the scope of this document. This field is static, and should contain the string 'major'. 5.10.3. eventTime Field The 'eventTime' field contains the agent system time when the access violation occurred. This field contains a string in 'dateTime' format. 5.10.4. eventSessionId Field The 'eventSessionId' field contains the session ID number for the session which had the access violation. This field contains a positive integer string. 5.10.5. eventSessionAddress Field The 'eventSessionAddress' field contains the Internet address for the session which had the access violation. This field contains an InetAddress string. 5.10.6. eventGroupName Field The 'eventGroupName' field identifies the group name associated with the session This field contains a string in NCX Name format. 5.10.7. eventAccessRequested Field The 'eventAccessRequested' field contains a string identifying the type of operation that was requested, which was denied access. This field contains an enumerated string with one of the following values: rpcRequest: An RPC method invocation request was denied. dataRead: A configuration data read request was denied. Bierman Expires February 6, 2008 [Page 52] Internet-Draft NCX-ACM August 2007 dataWrite: A configuration data write request was denied. 5.10.8. eventErrorPath Field The 'eventErrorPath' object contains an absolute Xpath expression identifying the RPC method, configuration data, RPC response field, or notification field that caused the access violation. This field contains a string conforming to the Xpath syntax. 5.10.9. accessDeniedEvent Example The following example shows a message for an example event. security major 2007-08-06T13:20:00.000-08:00 42 192.168.1.12 interns rpcRequest /nc:rpc/nc:edit-config Figure 15 This example shows an notification for an attempt (by a session for a user in the 'interns' group) to invoke the operation. Bierman Expires February 6, 2008 [Page 53] Internet-Draft NCX-ACM August 2007 6. Data Model XSD This section contains an XML Schema Definition [W3C.REC-xmlschema-2] which defines the XML syntax associated with the conceptual data structure semantics found in Section 5. BEGIN Module: ncx-acm Owner: ncx Application: security Version: 0.6 Contact Info: Send comments to ietf@andybierman.com. Description: NETCONF Access Control Model Parameters Bierman Expires February 6, 2008 [Page 54] Internet-Draft NCX-ACM August 2007 NCX System access control mode. off == no access control checking enforced warn == warn only if access violation detected loose == any RPC method in the netconf namespace can be invoked; read-only data allowed for all strict == ncxacl RPC entry must be present to invoke an RPC method; ncxacl Data entry must be present to access any data. (Except for user == 'root'.) Type of administrative role assigned to the session root == root account, no access control applied admin == administrative account, access control applied guest == guest account, read-only and configured access control applied. Bierman Expires February 6, 2008 [Page 55] Internet-Draft NCX-ACM August 2007 Type of request causing an access violation. rpcRequest: An RPC method invocation request was denied. dataRead: A configuration data read request was denied. dataWrite: A configuration data write request was denied. NCX Access Name string. (Should really be an extension of the 'NcxName' data type.) List of NcxAccessName strings. Bierman Expires February 6, 2008 [Page 56] Internet-Draft NCX-ACM August 2007 NCX RPC Type Classifications List NCX RPC Type Classifications sort NETCONF Data Access Types: none == no access allowed at all. This value is used in ACLs, not max-access clauses. read-only == read access allowed in all operations. This value implies notify access as well. read-write == all but create/delete allowed. Bierman Expires February 6, 2008 [Page 57] Internet-Draft NCX-ACM August 2007 Values can be read and edited. Merge and replace operations will be permitted, even (e.g., create the instance if it does not exist. This allows a manager to save static or agent-created entries in copy-config operations, and then reload them later. read-create == all access allowed Instances can be read, created, edited, and deleted. NCX Access Control Rule Type NCX Access Control Node Identifier Type Bierman Expires February 6, 2008 [Page 58] Internet-Draft NCX-ACM August 2007 Access Denied Event Notification Contents Read-only parameters indicating some agent access control capabilities. Bierman Expires February 6, 2008 [Page 59] Internet-Draft NCX-ACM August 2007 Read-write parameters controlling some global agent access control behavior. One NCX Group Membership Record The 'role' parameter should not be changed after it is set. If a user name is present in the 'users' table then it is a member of the group identified by 'name'. If a host address is present in the 'hosts' table then it is a member of the group identified by 'name'. If both 'users' and 'hosts' are missing then the group will be considered empty. Bierman Expires February 6, 2008 [Page 60] Internet-Draft NCX-ACM August 2007 NCX Group Membership Table Users and hosts can belong to any number of groups. The group name must be unique. One NCX RPC Method Access Control Rule Bierman Expires February 6, 2008 [Page 61] Internet-Draft NCX-ACM August 2007 NCX Access Control Rules for RPC Methods. One NCX Data Access Control Rule Bierman Expires February 6, 2008 [Page 62] Internet-Draft NCX-ACM August 2007 NCX Access Control Rules for Configuration Data One NCX Notification Access Control Rule NCX Access Control Rules for Notifications. Bierman Expires February 6, 2008 [Page 63] Internet-Draft NCX-ACM August 2007 Parameters for NETCONF Access Control. NCX ACM configuration supported by the agent read-only Bierman Expires February 6, 2008 [Page 64] Internet-Draft NCX-ACM August 2007 NCX Global Access Control Profile Parameters read-only NCX Group Membership Table read-create NCX RPC Execution Access Control Table read-create NCX Data Model Access Control Table read-create Bierman Expires February 6, 2008 [Page 65] Internet-Draft NCX-ACM August 2007 NCX Data Model Access Control Table read-create END Figure 16 Bierman Expires February 6, 2008 [Page 66] Internet-Draft NCX-ACM August 2007 7. IANA Considerations There are two actions that are requested of IANA: 1. register data model schema namespace URI 2. register data model schema URL and store associated XSD [namespace URI TBD] [namespace URL TBD] Bierman Expires February 6, 2008 [Page 67] Internet-Draft NCX-ACM August 2007 8. Security Considerations This entire document discusses access control requirements and mechanisms for restricting NETCONF protocol behavior within a given session. Configuration of the access control system is highly sensitive to system security. An agent may choose not to allow any user configuration to some portions of it, such as the global security level, or the groups which allowed access to system resources. If the agent chooses to allow user configuration of the access control system, then only sessions using the 'root' administrative role should be allowed to have write access to the data model. If the agent chooses to allow user retrieval of the access control system configuration, then only sessions using the 'root' administrative role should be allowed to have read access to the data model. Xpath expressions can be used for configuration of most access control rules. Care must be taken by the administrator to understand the ramifications of all terms within the Xpath expression, and make sure that it represents the intended evaluation criteria. There is a risk that invocation of non-standard RPC methods will have undocumented side effects. An administrator should construct access control rules such that the configuration database is protected from such side effects. Also, such RPC methods should never be invoked by a session using the 'root' administrative role. There is a risk that attackers may exploit bugs or side effects related to Xpath expression evaluation, which open security holes (i.e., grant access to groups that are not intended to have access) on a periodic or predictable basis, allowing an attacker more access than intended for short periods of time. There is a risk that non-standard RPC methods, or even the standard operation, may return data which 'aliases' or 'copies' sensitive data from a different data object. In this case, the namespace and/or the element name will not match the values for the sensitive data, which is then fully or partially copied into a different namespace and/or element. An administrator should avoid using data models which use this practice. An administrator should restrict write access to all configurable objects within this data model. It is suggested that only sessions using the 'root' administrative role be permitted to configure the Bierman Expires February 6, 2008 [Page 68] Internet-Draft NCX-ACM August 2007 data model defined in this document. If write access is allowed for configuration of access control rules, then care must be taken not to disrupt the access control security, such as deleting an access control rule which denies access to 'all'. It is suggested that the entire sent of rules (e.g., object, be replaced in one operation. For example, the object could be replaced by using the operation with a 'replace' operation attribute in the element. An administrator should restrict read access to the following objects within this data model, which reveal access control configuration: which could be considered sensitive. o groups o rpcRules o dataRules o notificationRules Bierman Expires February 6, 2008 [Page 69] Internet-Draft NCX-ACM August 2007 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. [W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- xml, October 2000, . [W3C.xpath] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", W3C Recommendation xpath, November 1999, . [W3C.REC-xmlschema-2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, . [I-D.ietf-netconf-notification] Trevino, H. and S. Chisholm, "NETCONF Event Notifications", draft-ietf-netconf-notification-08 (work in progress), July 2007. [I-D.bierman-ncx-smi] Bierman, A., "Network Configuration Extensions: Structure of Management Information", draft-bierman-ncx-smi-00 (work in progress), August 2007. 9.2. Informative References [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Bierman Expires February 6, 2008 [Page 70] Internet-Draft NCX-ACM August 2007 Author's Address Andy Bierman netconfcentral.org Simi Valley, CA USA Email: ietf@andybierman.com Bierman Expires February 6, 2008 [Page 71] Internet-Draft NCX-ACM August 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). Bierman Expires February 6, 2008 [Page 72]