Network Configuration Access Control Model
Extracted elements (31)
NACM applies access control at three distinct control points — protocol operation invocation, datastore data node access, and outgoing notification events — because NETCONF's extensible RPC model and YANG data modeling make it impossible to restrict access using only a static list of standard protocol operations.
No NACM access rights are required on data nodes that are implicitly changed as a side effect of an allowed operation (e.g., YANG when-stmt re-evaluation or choice-stmt branch exclusion), because requiring such permissions would create unworkable coupling between access control policy and YANG model semantics.
The nacm:default-deny-write and nacm:default-deny-all YANG extensions allow data model designers to embed machine-readable security annotations directly in YANG modules, eliminating a window of vulnerability that would otherwise exist between loading a new module and manually configuring corresponding NACM rules.
The write-default is 'deny' while read-default and exec-default are 'permit' by default, reflecting that unrestricted read and safe-operation execution is a common initial deployment posture, while inadvertent or malicious write access to configuration poses a higher security risk.
For <copy-config> from running to startup, only execute permission on the operation is required. For all other copy-config cases, the source is silently filtered for unreadable nodes and the target requires create/update/delete access on affected nodes.
For <get> and <get-config>, data nodes to which the client does not have read access are silently omitted (along with descendants) from the reply rather than generating an 'access-denied' error, so that NETCONF subtree and XPath filters operate against the subset of nodes the user can read.
Local files, remote files, and datastores accessed via the <url> parameter are not controlled by NACM; only conventional configuration datastores and the operational state datastore are subject to NACM enforcement.
RESTCONF HTTP methods are mapped to NETCONF operations for NACM purposes: GET/HEAD map to <get>/<get-config> (read), POST on data maps to <edit-config> (create), PUT on data maps to <edit-config> (create+update), PUT on datastore maps to <copy-config> (update), PATCH maps to <edit-config> (update), DELETE maps to <edit-config> (delete), POST on operation resource maps to the specified operation (execute), and OPTIONS maps to none (not subject to NACM).
A server MUST NOT include any information the client is not allowed to read in any <error-info> elements within the <rpc-error> response when access is denied.
A server MUST NOT vary its responses to RESTCONF OPTIONS and PATCH methods based on the existence of the underlying resource, which would indicate the presence or absence of resource instances; servers must always return 'access-denied' when the client lacks read permission.
Access to <delete-config> and <kill-session> is denied by default; the exec-default leaf does not apply to these operations, and access control rules must be explicitly configured to allow invocation by a non-recovery session.
For <commit>, 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 that set of nodes.
If a data node within a datastore is accessed or an action or notification is tied to a data node, 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.
The contents of specific restricted datastore nodes MUST NOT be exposed in any <rpc-error> elements within the reply from an <edit-config> operation.
The server MUST separately authorize every protocol operation by following the 12-step incoming RPC message validation procedure, checking enable-nacm, recovery session status, group membership, rule-list entries, nacm:default-deny-all annotations, and exec-default in order.
The server MUST use the access control rules in effect at the time it starts processing the message, and 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, if access control configuration is not present, a server MUST NOT allow any write access to any session role except a recovery session.
Access control is applied at the group level, not per individual user. A group contains zero or more members identified by username strings; one user may belong to multiple groups. Group membership can come from local configuration or from the transport layer (e.g., RADIUS) when enable-external-groups is true.
Five global enforcement controls govern NACM behavior: enable-nacm (on/off master switch, default true), read-default (permit/deny when no rule matches reads, default permit), write-default (permit/deny when no rule matches writes, default deny), exec-default (permit/deny when no rule matches execution, default permit), and enable-external-groups (whether transport-layer group names are honored, default true).
NACM defines five CRUDX access rights: Create (add a new data node instance), Read (read a data node or receive a notification), Update (modify an existing data node), Delete (remove a data node), and eXec (execute a protocol operation).
NACM defines four rule types: module rules (scope a YANG module by name), protocol-operation rules (match a specific RPC or action by module and name), data-node rules (match a data node and its descendants by XPath path), and notification rules (match a notification event type by module and name).
The nacm:default-deny-write YANG extension marks a data node as a sensitive security parameter; only a recovery session may write it unless an explicit NACM rule permits access. The nacm:default-deny-all extension additionally restricts all read, write, and execute access to recovery sessions by default.
The recovery session is a special administrative session that bypasses all NACM access control enforcement, intended for initializing or repairing the NACM configuration. The mechanism for identifying recovery sessions is implementation-specific and outside the scope of this document.
This document updates the IETF XML Registry entry and the YANG Module Names registry entry for 'ietf-netconf-acm' (namespace urn:ietf:params:xml:ns:yang:ietf-netconf-acm, prefix nacm) to reference RFC 8341 instead of RFC 6536.
A session with write access but without read access to a sensitive datastore subtree can perform 'fishing attacks' by issuing repeated create/update/delete requests and inferring the presence or absence of specific data from access-denied responses, even without the error-path field.
Because RESTCONF OPTIONS and PATCH responses are not subject to NACM, varying the response based on the existence of the underlying resource could allow unauthenticated or unauthorized clients to probe for the presence or absence of sensitive data. Servers must return a uniform 'access-denied' response regardless of resource existence when the client lacks read permission.
If external protocol mechanisms used to report group names to the transport layer do not protect against man-in-the-middle attacks, an attacker could inject group names to escalate a user's NACM permissions. Administrators may mitigate this by setting /nacm/enable-external-groups to 'false'.
The entire /nacm subtree is security-sensitive. Administrators must restrict both read access (which reveals access control configuration) and write access (which could disrupt enforcement) to all NACM data nodes, particularly when using :writable-running capability where edits take effect immediately.
Data node access validation follows a 13-step ordered procedure: check enable-nacm off, check recovery session, resolve groups, match rule-lists and rules, apply matching rule action, apply nacm:default-deny-all and nacm:default-deny-write annotations, then fall through to read-default, write-default, or exec-default depending on the operation type.
Incoming RPC message validation follows a 12-step ordered procedure: (1) check enable-nacm off, (2) check recovery session, (3) permit <close-session>, (4) resolve user groups, (5) skip if no groups found, (6-7) match rule-lists and rules in order, (8) apply matching rule action, (9-10) apply nacm:default-deny-all annotation check, (11) deny <kill-session>/<delete-config>, (12) apply exec-default.
Outgoing notification authorization follows an 11-step procedure analogous to data node access validation, additionally permitting <replayComplete> and <notificationComplete> event types unconditionally. If the notification is tied to a data subtree, read access to all ancestor data nodes is also required.