Network Configuration Protocol (NETCONF) Access Control Model

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.

The NACM data model provides the following features: Independent control of remote procedure call (RPC), action, data, and notification access. Simple access control rules configuration data model that is easy to use. The concept of an emergency recovery session is supported, but configuration of the server for this purpose is beyond the scope of this document. An emergency recovery session will bypass all access control enforcement, in order to allow it to initialize or repair the NACM configuration. A simple and familiar set of datastore permissions is used. Support for YANG security tagging (e.g., "nacm:default-deny-write" statement) allows default security modes to automatically exclude sensitive data. Separate default access modes for read, write, and execute permissions. Access control rules are applied to configurable groups of users. The access control enforcement procedures can be disabled during operation, without deleting any access control rules, in order to debug operational problems. Access control rules are simple to configure. The number of denied protocol operation requests and denied datastore write requests can be monitored by the client. Simple unconstrained YANG instance identifiers are used to configure access control rules for specific data nodes.

The NETCONF protocol is used for network management purposes within this document. The RESTCONF protocol is used for network management purposes within this document. The YANG Data Modeling Language is used to define the data models for use with the NETCONF or RESTCONF protocols. YANG is also used to define the data model in this document.

The following diagram shows the conceptual message flow model, including the points at which access control is applied during NETCONF message processing. RESTCONF operations are mapped to the access control model based on the HTTP method and resource class used in the operation. For example, a POST method on a data resource is considered "write data node" access, but a POST method on an operation resource is considered "operation" access.

| reply | | | | acc. ctl | | generator | | generator | +===========+ +-------------+ +----------------+ | ^ ^ ^ V +------+ | | +-----------+ | +=============+ +================+ | operation | | | read | | | | processor |-+ | data node | | access ctl | | | | acc. ctl | | | +-----------+ +=============+ +================+ | | ^ ^ ^ V +----------------+ | | | +===========+ | | | +============+ | write | | | | | pre-read | | data node | | | | | data node | | acc. ctl | -----------+ | | | | acc. ctl | +===========+ | | | | +============+ | | | | | ^ V V V | | | +---------------+ +-------------------+ | configuration | ---> | server | | datastore | | instrumentation | | | <--- | | +---------------+ +-------------------+]]> The following high-level sequence of conceptual processing steps is executed for each received <rpc> message, if access control enforcement is enabled: For each active session, access control is applied individually to all <rpc> messages (except <close-session>) received by the server, unless the session is identified as a recovery session. If the <action> operation defined in is invoked, then read access is required for all instances in the hierarchy of data nodes that identifies the specific action in the datastore, and execute access is required for the action node. If the user is not authorized to read all the specified data nodes and execute the action, then the request is rejected with an "access-denied" error. Otherwise, if the user is not authorized to execute the specified protocol operation, then the request is rejected with an "access-denied" error. If the configuration datastore or conceptual state data is accessed by the protocol operation, then the server checks if the client is authorized to access the nodes in the datastore. If the user is not authorized to perform the requested access operation on the requested data, then the request is rejected with an "access-denied" error. The following sequence of conceptual processing steps is executed for each generated notification event, if access control enforcement is enabled: Server instrumentation generates a notification for a particular subscription. If the notification statement is specified within a data subtree, as specified in , then read access is required for all instances in the hierarchy of data nodes that identifies the specific notification in the datastore, and read access is required for the notification node. If the user is not authorized to read all the specified data nodes and the notification node, then the notification is dropped for that subscription. If the notification statement is a top-level statement, the notification access control enforcer checks the notification event type, and if it is one that the user is not authorized to read, then the notification is dropped for that subscription.

The same access control rules apply to all datastores, for example, the candidate configuration datastore or the running configuration datastore. Only the standard NETCONF datastores (candidate, running, and startup) are controlled by NACM. Local or remote files or datastores accessed via the <url> parameter are not controlled by NACM. A standalone RESTCONF server (i.e., not co-located with a NETCONF server) applies NACM rules to a conceptual datastore, since datastores are not supported in RESTCONF.

A small set of hard-wired datastore access rights is needed to control access to all possible NETCONF protocol operations, including vendor extensions to the standard protocol operation set. The "CRUDX" model can support all NETCONF protocol operations: Create: allows the client to add a new data node instance to a datastore. Read: allows the client to read a data node instance from a datastore or receive the notification event type. Update: allows the client to update an existing data node instance in a datastore. Delete: allows the client to delete a data node instance from a datastore. eXec: allows the client to execute the operation.

The RESTCONF protocol utilizes HTTP methods to perform datastore operations, similar to the NETCONF protocol. The NACM procedures were originally written for NETCONF protocol operations so the RESTCONF methods are mapped to NETCONF operations for the purpose of access control processing. The enforcement procedures described within this document apply to both protocols unless explicitly stated otherwise. The request URI needs to be considered when processing RESTCONF requests on data resources: For HEAD and GET requests, any data nodes which are ancestor nodes of the target resource are considered to be part of the retrieval request for access control purposes. For PUT, PATCH, and DELETE requests, any data nodes which are ancestor nodes of the target resource are not considered to be part of the edit request for access control purposes. The edit operation for these nodes is considered to be 'none'. The edit begins at the target resource. For POST requests on data resources, any data nodes which are specified in the request URI, including the target resource, are not considered to be part of the edit request for access control purposes. The edit operation for these nodes is considered to be 'none'. The edit begins at a child node of the target resource, specified in the message body. Not all RESTCONF methods are subject to access control. The following table specifies how each method is mapped to NETCONF protocol operations. The value 'none' indicates that NACM is not applied at all to the specific RESTCONF method. method resource class NETCONF operation Edit operation OPTIONS all none N/A HEAD all <get> N/A GET all <get> N/A POST datastore, data <edit-config> create POST operation specified operation N/A PUT data <edit-config> create, replace PUT datastore <copy-config> replace PATCH data, datastore <edit-config> merge DELETE data <edit-config> delete

Data nodes to which the client does not have read access are silently omitted from the <rpc-reply> message. This is done to allow NETCONF filters for <get> and <get-config> to function properly, instead of causing an "access-denied" error because the filter criteria would otherwise include unauthorized read access to some data nodes. For NETCONF filtering purposes, the selection criteria is applied to the subset of nodes that the user is authorized to read, not the entire datastore.

The NACM access rights are not directly coupled to the <edit-config> "operation" attribute, although they are similar. Instead, a NACM access right applies to all protocol operations that would result in a particular access operation to the target datastore. This section describes how these access rights apply to the specific access operations supported by the <edit-config> protocol operation. If the effective access operation is "none" (i.e., default-operation="none") for a particular data node, then no access control is applied to that data node. This is required to allow access to a subtree within a larger data structure. For example, a user may be authorized to create a new "/interfaces/interface" list entry but not be authorized to create or delete its parent container ("/interfaces"). If the "/interfaces" container already exists in the target datastore, then the effective operation will be "none" for the "/interfaces" node if an "/interfaces/interface" list entry is edited. If the protocol operation would result in the creation of a datastore node and the user does not have "create" access permission for that node, the protocol operation is rejected with an "access-denied" error. If the protocol operation would result in the deletion of a datastore node and the user does not have "delete" access permission for that node, the protocol operation is rejected with an "access-denied" error. If the protocol operation would result in the modification of a datastore node and the user does not have "update" access permission for that node, the protocol operation is rejected with an "access-denied" error. A "merge" or "replace" <edit-config> operation may include data nodes that do not alter portions of the existing datastore. For example, a container or list node may be present for naming purposes but does not actually alter the corresponding datastore node. These unaltered data nodes are ignored by the server and do not require any access rights by the client. A "merge" <edit-config> operation may include data nodes but not include particular child data nodes that are present in the datastore. These missing data nodes within the scope of a "merge" <edit-config> operation are ignored by the server and do not require any access rights by the client. The contents of specific restricted datastore nodes MUST NOT be exposed in any <rpc-error> elements within the reply.

Access control for the <copy-config> protocol operation requires special consideration because the administrator may be replacing the entire target datastore. If the source of the <copy-config> protocol operation is the running configuration datastore and the target is the startup configuration datastore, the client is only required to have permission to execute the <copy-config> protocol operation. Otherwise: If the source of the <copy-config> operation is a datastore, then data nodes to which the client does not have read access are silently omitted. If the target of the <copy-config> operation is a datastore, the client needs access to the modified nodes, specifically: If the protocol operation would result in the creation of a datastore node and the user does not have "create" access permission for that node, the protocol operation is rejected with an "access-denied" error. If the protocol operation would result in the deletion of a datastore node and the user does not have "delete" access permission for that node, the protocol operation is rejected with an "access-denied" error. If the protocol operation would result in the modification of a datastore node and the user does not have "update" access permission for that node, the protocol operation is rejected with an "access-denied" error.

Access to the <delete-config> protocol operation is denied by default. The "exec-default" leaf does not apply to this protocol operation. Access control rules must be explicitly configured to allow invocation by a non-recovery session.

The server MUST determine the exact nodes in the running configuration datastore that are actually different and only check "create", "update", and "delete" access permissions for this set of nodes, which could be empty. For example, if a session can read the entire datastore but only change one leaf, that session needs to be able to edit and commit that one leaf.

The client is only required to have permission to execute the <discard-changes> protocol operation. No datastore permissions are needed.

The <kill-session> operation does not directly alter a datastore. However, it allows one session to disrupt another session that is editing a datastore. Access to the <kill-session> protocol operation is denied by default. The "exec-default" leaf does not apply to this protocol operation. Access control rules must be explicitly configured to allow invocation by a non-recovery session.

This section defines the conceptual components related to the access control model.

A "user" is the conceptual entity that is associated with the access permissions granted to a particular session. A user is identified by a string that is unique within the server. As described in , the username string is derived from the transport layer during session establishment. If the transport layer cannot authenticate the user, the session is terminated.

Access to a specific NETCONF protocol operation is granted to a session, associated with a group, not a user. A group is identified by its name. All group names are unique within the server. A group member is identified by a username string. The same user can be a member of multiple groups.

The server MAY support a recovery session mechanism, which will bypass all access control enforcement. This is useful for restricting initial access and repairing a broken access control configuration.

There are five global controls that are used to help control how access control is enforced.

A global "enable-nacm" on/off switch is provided to enable or disable all access control enforcement. When this global switch is set to "true", then all requests are checked against the access control rules and only permitted if configured to allow the specific access request. When this global switch is set to "false", then all access requested are permitted.

An on/off "read-default" switch is provided to enable or disable default access to receive data in replies and notifications. When the "enable-nacm" global switch is set to "true", then this global switch is relevant if no matching access control rule is found to explicitly permit or deny read access to the requested NETCONF datastore data or notification event type. When this global switch is set to "permit" and no matching access control rule is found for the NETCONF datastore read or notification event requested, then access is permitted. When this global switch is set to "deny" and no matching access control rule is found for the NETCONF datastore read or notification event requested, then access is denied.

An on/off "write-default" switch is provided to enable or disable default access to alter configuration data. When the "enable-nacm" global switch is set to "true", then this global switch is relevant if no matching access control rule is found to explicitly permit or deny write access to the requested NETCONF datastore data. When this global switch is set to "permit" and no matching access control rule is found for the NETCONF datastore write requested, then access is permitted. When this global switch is set to "deny" and no matching access control rule is found for the NETCONF datastore write requested, then access is denied.

An on/off "exec-default" switch is provided to enable or disable default access to execute protocol operations. When the "enable-nacm" global switch is set to "true", then this global switch is relevant if no matching access control rule is found to explicitly permit or deny access to the requested NETCONF protocol operation. When this global switch is set to "permit" and no matching access control rule is found for the NETCONF protocol operation requested, then access is permitted. When this global switch is set to "deny" and no matching access control rule is found for the NETCONF protocol operation requested, then access is denied.

When this global switch is set to "true", the group names reported by the NETCONF transport layer for a session are used together with the locally configured group names to determine the access control rules for the session. When this switch is set to "false", the group names reported by the NETCONF transport layer are ignored by NACM.

There are four types of rules available in NACM: controls access for definitions in a specific YANG module, identified by its name. controls access for a specific protocol operation, identified by its YANG module and name. controls access for a specific data node, identified by its path location within the conceptual XML document for the data node. controls access for a specific notification event type, identified by its YANG module and name.

There are seven separate phases that need to be addressed, four of which are related to the NETCONF message processing model (). In addition, the initial startup mode for a NETCONF server, session establishment, and "access-denied" error-handling procedures also need to be considered. The server MUST use the access control rules in effect at the time it starts processing the message. The same access control rules MUST stay in effect for the processing of the entire message.

Upon the very first startup of the NETCONF server, the access control configuration will probably not be present. If it isn't, a server MUST NOT allow any write access to any session role except a recovery session. Access rules are enforced any time a request is initiated from a user session. Access control is not enforced for server-initiated access requests, such as the initial load of the running datastore, during bootup.

The access control model applies specifically to the well-formed XML content transferred between a client and a server after session establishment has been completed and after the <hello> exchange has been successfully completed. Once session establishment is completed and a user has been authenticated, the NETCONF transport layer reports the username and a possibly empty set of group names associated with the user to the NETCONF server. The NETCONF server will enforce the access control rules, based on the supplied username, group names, and the configuration data stored on the server.

The "access-denied" error-tag is generated when the access control system denies access to either a request to invoke a protocol operation or a request to perform a particular access operation on the configuration datastore. A server MUST NOT include any information the client is not allowed to read in any <error-info> elements within the <rpc-error> response.

The diagram below shows the basic conceptual structure of the access control processing model for incoming NETCONF <rpc> messages within a server.

| +------------+ | | | | | +-------------------------+ | +------------+ | V V V +-----------+ +---------------+ +------------+ | Vendor NS | | NC-base NS | | NC-base NS | | | | | | | +-----------+ +---------------+ +------------+ | | | | V V +----------------------+ | | | configuration | | datastore | +----------------------+]]> Access control begins with the message dispatcher. After the server validates the <rpc> element and determines the namespace URI and the element name of the protocol operation being requested, the server verifies that the user is authorized to invoke the protocol operation. The server MUST separately authorize every protocol operation by following these steps: If the "enable-nacm" leaf is set to "false", then the protocol operation is permitted. If the requesting session is identified as a recovery session, then the protocol operation is permitted. If the requested operation is the NETCONF <close-session> protocol operation, then the protocol operation is permitted. Check all the "group" entries for ones that contain a "user-name" entry that equals the username for the session making the request. If the "enable-external-groups" leaf is "true", add to these groups the set of groups provided by the transport layer. If no groups are found, continue with step 10. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met: The rule's "module-name" leaf is "*" or equals the name of the YANG module where the protocol operation is defined. The rule does not have a "rule-type" defined or the "rule-type" is "protocol-operation" and the "rpc-name" is "*" or equals the name of the requested protocol operation. The rule's "access-operations" leaf has the "exec" bit set or has the special value "*". If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then the protocol operation is permitted; otherwise, it is denied. At this point, no matching rule was found in any rule-list entry. If the requested protocol operation is defined in a YANG module advertised in the server capabilities and the "rpc" statement contains a "nacm:default-deny-all" statement, then the protocol operation is denied. If the requested protocol operation is the NETCONF <kill-session> or <delete-config>, then the protocol operation is denied. If the "exec-default" leaf is set to "permit", then permit the protocol operation; otherwise, deny the request. If the user is not authorized to invoke the protocol operation, then an <rpc-error> is generated with the following information: access-denied Identifies the requested protocol operation. The following example represents the <edit-config> protocol operation in the NETCONF base namespace:

/nc:rpc/nc:edit-config ]]> If a datastore is accessed, either directly or as a side effect of the protocol operation, then the server MUST intercept the access operation and make sure the user is authorized to perform the requested access operation on the specified data, as defined in .

If a data node within a datastore is accessed, or an action or notification tied to a data node, then the server MUST ensure that the user is authorized to perform the requested "read", "create", "update", "delete", or "execute" access operation on the specified data node. If an action is requested to be executed, the server MUST ensure that the user is authorized to perform the "execute" access operation on the requested action. If a notification tied to a data node is generated, the server MUST ensure that the user is authorized to perform the "read" access operation on the requested notification. The data node access request is authorized by following these steps: If the "enable-nacm" leaf is set to "false", then the access operation is permitted. If the requesting session is identified as a recovery session, then the access operation is permitted. Check all the "group" entries for ones that contain a "user-name" entry that equals the username for the session making the request. If the "enable-external-groups" leaf is "true", add to these groups the set of groups provided by the transport layer. If no groups are found, continue with step 9. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met: The rule's "module-name" leaf is "*" or equals the name of the YANG module where the requested data node is defined. The rule does not have a "rule-type" defined or the "rule-type" is "data-node" and the "path" matches the requested data node, action node, or notification node. For a "read" access operation, the rule's "access-operations" leaf has the "read" bit set or has the special value "*". For a "create" access operation, the rule's "access-operations" leaf has the "create" bit set or has the special value "*". For a "delete" access operation, the rule's "access-operations" leaf has the "delete" bit set or has the special value "*". For an "update" access operation, the rule's "access-operations" leaf has the "update" bit set or has the special value "*". For an "execute" access operation, the rule's "access-operations" leaf has the "exec" bit set or has the special value "*". If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then the data node access is permitted; otherwise, it is denied. For a "read" access operation, "denied" means that the requested data is not returned in the reply. At this point, no matching rule was found in any rule-list entry. For a "read" access operation, if the requested data node is defined in a YANG module advertised in the server capabilities and the data definition statement contains a "nacm:default-deny-all" statement, then the requested data node is not included in the reply. For a "write" access operation, if the requested data node is defined in a YANG module advertised in the server capabilities and the data definition statement contains a "nacm:default-deny-write" or a "nacm:default-deny-all" statement, then the data node access request is denied. For a "read" access operation, if the "read-default" leaf is set to "permit", then include the requested data node in the reply; otherwise, do not include the requested data node in the reply. For a "write" access operation, if the "write-default" leaf is set to "permit", then permit the data node access request; otherwise, deny the request. For an "execute" access operation, if the "exec-default" leaf is set to "permit", then permit the request; otherwise, deny the request.

Configuration of access control rules specifically for descendant nodes of the notification event type element are outside the scope of this document. If the user is authorized to receive the notification event type, then it is also authorized to receive any data it contains. If the notification is specified within a data subtree, as specified in , then read access to the notification is required. Processing continues as described in . The following figure shows the conceptual message processing model for outgoing <notification> messages.

| | generator | +----------------+ ^ | +=================+ | | | access control | | | +=================+ ^ | +------------------------+ | server instrumentation | +------------------------+ | ^ V | +----------------------+ | configuration | | datastore | +----------------------+ ]]> The generation of a notification for a specific subscription is authorized by following these steps: If the "enable-nacm" leaf is set to "false", then the notification is permitted. If the session is identified as a recovery session, then the notification is permitted. If the notification is the NETCONF <replayComplete> or <notificationComplete> event type , then the notification is permitted. Check all the "group" entries for ones that contain a "user-name" entry that equals the username for the session making the request. If the "enable-external-groups" leaf is "true", add to these groups the set of groups provided by the transport layer. If no groups are found, continue with step 10. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met: The rule's "module-name" leaf is "*" or equals the name of the YANG module where the notification is defined. The rule does not have a "rule-type" defined or the "rule-type" is "notification" and the "notification-name" is "*" or equals the name of the notification. The rule's "access-operations" leaf has the "read" bit set or has the special value "*". If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then permit the notification; otherwise, drop the notification for the associated subscription. Otherwise, no matching rule was found in any rule-list entry. If the requested notification is defined in a YANG module advertised in the server capabilities and the "notification" statement contains a "nacm:default-deny-all" statement, then the notification is dropped for the associated subscription. If the "read-default" leaf is set to "permit", then permit the notification; otherwise, drop the notification for the associated subscription.

The following diagram highlights the contents and structure of the NACM YANG module.

The following YANG module specifies the normative NETCONF content that MUST by supported by the server. The "ietf-netconf-acm" YANG module imports typedefs from .

file "ietf-netconf-acm@2016-08-26.yang" module ietf-netconf-acm { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm"; prefix "nacm"; import ietf-yang-types { prefix yang; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: Author: Andy Bierman Author: Martin Bjorklund "; description "NETCONF Access Control Model. Copyright (c) 2012, 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision "2016-08-26" { description "Second version"; reference "RFC XXXX: Network Configuration Protocol (NETCONF) Access Control Model"; } revision "2012-02-22" { description "Initial version"; reference "RFC 6536: Network Configuration Protocol (NETCONF) Access Control Model"; } /* * Extension statements */ extension default-deny-write { description "Used to indicate that the data model node represents a sensitive security system parameter. If present, and the NACM module is enabled (i.e., /nacm/enable-nacm object equals 'true'), the NETCONF server will only allow the designated 'recovery session' to have write access to the node. An explicit access control rule is required for all other users. The 'default-deny-write' extension MAY appear within a data definition statement. It is ignored otherwise."; } extension default-deny-all { description "Used to indicate that the data model node controls a very sensitive security system parameter. If present, and the NACM module is enabled (i.e., /nacm/enable-nacm object equals 'true'), the NETCONF server will only allow the designated 'recovery session' to have read, write, or execute access to the node. An explicit access control rule is required for all other users. The 'default-deny-all' extension MAY appear within a data definition statement, 'rpc' statement, or 'notification' statement. It is ignored otherwise."; } /* * Derived types */ typedef user-name-type { type string { length "1..max"; } description "General Purpose Username string."; } typedef matchall-string-type { type string { pattern '\*'; } description "The string containing a single asterisk '*' is used to conceptually represent all possible values for the particular leaf using this data type."; } typedef access-operations-type { type bits { bit create { description "Any protocol operation that creates a new data node."; } bit read { description "Any protocol operation or notification that returns the value of a data node."; } bit update { description "Any protocol operation that alters an existing data node."; } bit delete { description "Any protocol operation that removes a data node."; } bit exec { description "Execution access to the specified protocol operation."; } } description "NETCONF Access Operation."; } typedef group-name-type { type string { length "1..max"; pattern '[^\*].*'; } description "Name of administrative group to which users can be assigned."; } typedef action-type { type enumeration { enum permit { description "Requested action is permitted."; } enum deny { description "Requested action is denied."; } } description "Action taken by the server when a particular rule matches."; } typedef node-instance-identifier { type yang:xpath1.0; description "Path expression used to represent a special data node, action, or notification instance identifier string. A node-instance-identifier value is an unrestricted YANG instance-identifier expression. All the same rules as an instance-identifier apply except predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key. This XPath expression is evaluated in the following context: o The set of namespace declarations are those in scope on the leaf element where this type is used. o The set of variable bindings contains one variable, 'USER', which contains the name of the user of the current session. o The function library is the core function library, but note that due to the syntax restrictions of an instance-identifier, no functions are allowed. o The context node is the root node in the data tree. The accessible tree includes actions and notifications tied to data nodes."; } /* * Data definition statements */ container nacm { nacm:default-deny-all; description "Parameters for NETCONF Access Control Model."; leaf enable-nacm { type boolean; default true; description "Enables or disables all NETCONF access control enforcement. If 'true', then enforcement is enabled. If 'false', then enforcement is disabled."; } leaf read-default { type action-type; default "permit"; description "Controls whether read access is granted if no appropriate rule is found for a particular read request."; } leaf write-default { type action-type; default "deny"; description "Controls whether create, update, or delete access is granted if no appropriate rule is found for a particular write request."; } leaf exec-default { type action-type; default "permit"; description "Controls whether exec access is granted if no appropriate rule is found for a particular protocol operation request."; } leaf enable-external-groups { type boolean; default true; description "Controls whether the server uses the groups reported by the NETCONF transport layer when it assigns the user to a set of NACM groups. If this leaf has the value 'false', any group names reported by the transport layer are ignored by the server."; } leaf denied-operations { type yang:zero-based-counter32; config false; mandatory true; description "Number of times since the server last restarted that a protocol operation request was denied."; } leaf denied-data-writes { type yang:zero-based-counter32; config false; mandatory true; description "Number of times since the server last restarted that a protocol operation request to alter a configuration datastore was denied."; } leaf denied-notifications { type yang:zero-based-counter32; config false; mandatory true; description "Number of times since the server last restarted that a notification was dropped for a subscription because access to the event type was denied."; } container groups { description "NETCONF Access Control Groups."; list group { key name; description "One NACM Group Entry. This list will only contain configured entries, not any entries learned from any transport protocols."; leaf name { type group-name-type; description "Group name associated with this entry."; } leaf-list user-name { type user-name-type; description "Each entry identifies the username of a member of the group associated with this entry."; } } } list rule-list { key "name"; ordered-by user; description "An ordered collection of access control rules."; leaf name { type string { length "1..max"; } description "Arbitrary name assigned to the rule-list."; } leaf-list group { type union { type matchall-string-type; type group-name-type; } description "List of administrative groups that will be assigned the associated access rights defined by the 'rule' list. The string '*' indicates that all groups apply to the entry."; } list rule { key "name"; ordered-by user; description "One access control rule. Rules are processed in user-defined order until a match is found. A rule matches if 'module-name', 'rule-type', and 'access-operations' match the request. If a rule matches, the 'action' leaf determines if access is granted or not."; leaf name { type string { length "1..max"; } description "Arbitrary name assigned to the rule."; } leaf module-name { type union { type matchall-string-type; type string; } default "*"; description "Name of the module associated with this rule. This leaf matches if it has the value '*' or if the object being accessed is defined in the module with the specified module name."; } choice rule-type { description "This choice matches if all leafs present in the rule match the request. If no leafs are present, the choice matches all requests."; case protocol-operation { leaf rpc-name { type union { type matchall-string-type; type string; } description "This leaf matches if it has the value '*' or if its value equals the requested protocol operation name."; } } case notification { leaf notification-name { type union { type matchall-string-type; type string; } description "This leaf matches if it has the value '*' or if its value equals the requested notification name."; } } case data-node { leaf path { type node-instance-identifier; mandatory true; description "Data Node Instance Identifier associated with the data node controlled by this rule. Configuration data or state data instance identifiers start with a top-level data node. A complete instance identifier is required for this type of path value. The special value '/' refers to all possible datastore contents."; } } } leaf access-operations { type union { type matchall-string-type; type access-operations-type; } default "*"; description "Access operations associated with this rule. This leaf matches if it has the value '*' or if the bit corresponding to the requested operation is set."; } leaf action { type action-type; mandatory true; description "The access control action associated with the rule. If a rule is determined to match a particular request, then this object is used to determine whether to permit or deny the request."; } leaf comment { type string; description "A textual description of the access rule."; } } } } }

]]>



   
     
       This document reuses the URI for "ietf-netconf-acm"
       in "The IETF XML Registry".
     
     
       This document updates the module registration in the
       "YANG Module Names" registry to reference
       this RFC instead of RFC 6536.

       Following the format in ,
       the following has been registered.

       
         
       
     
   

   
     
       This entire document discusses access control
       requirements and mechanisms for restricting
       NETCONF protocol behavior within a given session.
     
     
       This section highlights the issues for an administrator
       to consider when configuring a NETCONF server with NACM.
     
     
       
         Configuration of the access control system is
         highly sensitive to system security.  A server may
         choose not to allow any user configuration to
         some portions of it, such as the global security level
         or the groups that allowed access to system resources.
       
       
         By default, NACM enforcement is enabled.
         By default, "read" access to all datastore contents is enabled
         (unless "nacm:default-deny-all" is specified for the data definition),
         and "exec" access is enabled for safe protocol operations.
         An administrator needs to ensure that NACM is enabled
         and also decide if the default access parameters are
         set appropriately.  Make sure the following data nodes
         are properly configured:
         
           /nacm/enable-nacm (default "true")
           /nacm/read-default (default "permit")
           /nacm/write-default (default "deny")
           /nacm/exec-default (default "permit")
         
       
       
         An administrator needs to restrict write access to all
         configurable objects within this data model.
       
       
         If write access is allowed for configuration of
         access control rules, then care needs to be taken
         not to disrupt the access control enforcement.
         For example, if the NACM access control rules are edited directly
         within the running configuration datastore (i.e.,
         :writable-running capability is supported and used),
         then care needs to be taken not to allow unintended
         access while the edits are being done.
       
       
         An administrator needs to make sure that
         the translation from a transport- or implementation-dependent
         user identity to a NACM username is unique
         and correct.
         This requirement is specified in detail in Section 2.2
         of .
       
       
         An administrator needs to be aware that the YANG data structures
         representing access control rules (/nacm/rule-list
         and /nacm/rule-list/rule)
         are ordered by the client.  The server will evaluate the
         access control rules according to their relative conceptual order
         within the running datastore configuration.
       
       
         Note that the /nacm/groups data structure contains
         the administrative group names used by the server.
         These group names may be configured locally and/or
         provided through an external protocol, such as RADIUS
         .
       
       
         An administrator needs to be aware of the security properties
         of any external protocol used by the NETCONF transport layer
         to determine group names.  For example, if this protocol does
         not protect against man-in-the-middle attacks, an attacker
         might be able to inject group names that are configured in
         NACM, so that a user gets more permissions than it should.
         In such cases, the administrator may wish to disable the
         usage of such group names, by setting
         /nacm/enable-external-groups to "false".
       
       
         An administrator needs to restrict read access to the
         following objects within this data model, as they reveal
         access control configuration that could be considered
         sensitive.
         
           /nacm/enable-nacm
           /nacm/read-default
           /nacm/write-default
           /nacm/exec-default
           /nacm/enable-external-groups
           /nacm/groups
           /nacm/rule-list
         
       
     

     
       
         There is a risk that invocation of
         non-standard protocol operations will have undocumented side effects.
         An administrator needs to construct access control rules
         such that the configuration datastore is protected
         from such side effects.
       
       
         It is possible for a session with some write access
         (e.g., allowed to invoke <edit-config>),
         but without any access to a particular datastore subtree
         containing sensitive data, to determine the presence
         or non-presence of that data.
         This can be done by repeatedly issuing
         some sort of edit request (create, update, or delete)
         and possibly receiving "access-denied" errors in response.
         These "fishing" attacks can identify the presence or
         non-presence of specific sensitive data even without
         the "error-path" field being present within the <rpc-error>
         response.
       
       
         It may be possible for the set of NETCONF capabilities
         on the server to change over time.  If so, then there is a risk
         that new protocol operations, notifications, and/or
         datastore content have been added to the device.
         An administrator needs to be sure the access control
         rules are correct for the new content in this case.
         Mechanisms to detect NETCONF capability changes on
         a specific device are outside the scope of this document.
       
       
         It is possible that the data model definition itself
         (e.g., YANG when-stmt) will help an unauthorized session
         determine the presence or even value of sensitive data nodes
         by examining the presence and values of different data nodes.
       
       
         There is a risk that non-standard protocol operations, or
         even the standard <get> protocol operation, may
         return data that "aliases" or "copies" sensitive data
         from a different data object.  There may simply be
         multiple data model definitions that expose
         or even configure the same underlying system
         instrumentation.
       
       
         A data model may contain external keys
         (e.g., YANG leafref), which expose values
         from a different data structure.
         An administrator needs to
         be aware of sensitive data models that contain leafref nodes.
         This entails finding all the leafref objects that
         "point" at the sensitive data (i.e., "path-stmt" values) that
         implicitly or explicitly include the sensitive data node.
       
       
         It is beyond the scope of this document to define access
         control enforcement
         procedures for underlying device instrumentation that may
         exist to support the NETCONF server operation.  An administrator
         can identify each protocol operation that the server provides
         and decide if it needs any access control applied to it.
       
       
         This document incorporates the optional use of a recovery session
         mechanism, which can be used to bypass access control
         enforcement in emergencies, such as NACM configuration errors
         that disable all access to the server.
         The configuration and identification of such
         a recovery session mechanism are implementation-specific
         and outside the scope of this document.
         An administrator needs to be aware of any recovery session
         mechanisms available on the device and make sure they
         are used appropriately.
       
       
         It is possible for a session to disrupt configuration
         management, even without any write access to the configuration,
         by locking the datastore. This may be done to ensure all or
         part of the configuration  remains stable while it is being
         retrieved, or it may be done as a "denial-of-service" attack.
         There is no way for the server to know the difference.
         An administrator may wish to
         restrict "exec" access to the following protocol operations:
         
           <lock>
           <unlock>
           <partial-lock>
           <partial-unlock>
         
       
     
     
       
         Designers need to clearly identify any sensitive data,
         notifications, or protocol operations defined within a YANG
         module.  For such definitions, a "nacm:default-deny-write" or
         "nacm:default-deny-all" statement ought to be present, in
         addition to a clear description of the security risks.
       
       
         Protocol operations need to be properly documented by the
         data model designer, so it is clear to administrators what
         data nodes (if any) are affected by the protocol operation
         and what information (if any) is returned in the
         <rpc-reply> message.
       
       
         Data models ought to be designed so that different access
         levels for input parameters to protocol operations are not required.
         Use of generic protocol operations should be avoided, and if different access levels
         are needed, separate
         protocol operations should be defined instead.