Network Configuration Protocol (NETCONF) Access Control Model
obsoleted by
- rfc-8341 — Network Configuration Access Control Model
Extracted elements (30)
For <get> and <get-config>, inaccessible data nodes are silently omitted from the reply rather than generating an access-denied error. This allows NETCONF subtree and XPath filters to function correctly against the authorized subset of the datastore, rather than failing when filter criteria span unauthorized nodes.
Machine-readable YANG extension statements (nacm:default-deny-write and nacm:default-deny-all) were introduced to eliminate a window of vulnerability between loading a new data model and manually configuring access control rules; tools can automatically deny access to sensitive data without administrator intervention.
NACM provides three separate access control points — protocol operation invocation, datastore data node access, and notification delivery — because NETCONF allows new protocol operations to be added at any time via YANG, making a static operation-only ACM insufficient for comprehensive protection.
The <copy-config> operation from running to startup requires only exec permission (no per-node checks), because copying between these two standard datastores is a common administrative operation and the data already exists in the running datastore. All other copy-config operations require per-node CRUDX checks.
NACM access control is applied only after session establishment is completed and the NETCONF <hello> exchange has been successfully completed. Access control for descendant nodes within a notification event type is not separately controllable; if the event type is authorized, all contained data is also authorized.
NACM controls only the standard NETCONF datastores (candidate, running, and startup). Local or remote files and datastores accessed via the <url> parameter are not controlled by 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 generated for an access-denied condition.
Access to the <delete-config> protocol operation is denied by default; the exec-default leaf does not apply to it, and explicit access control rules must be configured to allow invocation by non-recovery sessions.
Access to the <kill-session> protocol operation is denied by default; the exec-default leaf does not apply to it, and explicit access control rules must be configured to allow invocation by non-recovery sessions.
For the <commit> operation, 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 delta set.
If a datastore is accessed directly or as a side effect of a protocol operation, the server MUST intercept the access operation and verify the user is authorized to perform the requested CRUDX operation on the specified data node as defined in the data node access validation procedure.
The contents of specific restricted datastore nodes MUST NOT be exposed in any <rpc-error> elements within the reply; this applies to the <edit-config> operation and any operation that accesses the datastore.
The server MUST separately authorize every protocol operation by executing a 12-step procedure: checking enable-nacm, recovery session status, close-session exemption, group membership (including external groups if enabled), ordered rule-list and rule matching, default-deny-all extension check, kill-session/delete-config implicit denial, and exec-default fallback.
The server MUST use the access control rules in effect at the time it starts processing a message, and the same rules MUST stay in effect for the entire duration of that message's processing.
Upon the very first startup, if NACM configuration is absent, a server MUST NOT allow any write access to any session role except a recovery session. Access control is not enforced for server-initiated access during bootup.
Access control is granted to sessions by group membership, not directly to individual users. The groups container maps usernames to named groups; a user may belong to multiple groups. Transport-layer-reported group names (e.g., from RADIUS) may optionally supplement locally configured groups.
Five global enforcement controls govern NACM behavior: enable-nacm (master on/off, default true), read-default (permit/deny for reads with no matching rule, default permit), write-default (default deny), exec-default (default permit), and enable-external-groups (whether transport-layer group names are used, default true).
NACM defines five CRUDX access operations: Create (add a new data node instance), Read (retrieve a data node value or receive a notification), Update (alter an existing data node), Delete (remove a data node), and eXec (execute a protocol operation).
NACM defines four rule types: module rule (controls all content in a named YANG module), protocol-operation rule (controls a specific RPC identified by module and name), data-node rule (controls access by XPath instance identifier path), and notification rule (controls a specific notification event type).
The nacm:default-deny-all YANG extension marks a node as controlling a very sensitive security parameter; when NACM is enabled, only a recovery session has any access (read, write, or execute) by default. It may appear in data definition, rpc, or notification statements.
The nacm:default-deny-write YANG extension marks a data model node as a sensitive security parameter; when NACM is enabled, only a recovery session has write access by default, requiring an explicit access control rule for all other users.
The server MAY support an emergency recovery session that bypasses all NACM enforcement; its configuration and identification are implementation-specific and out of scope. It is intended for initializing or repairing broken NACM configuration.
Three read-only operational counters track enforcement activity since last restart: denied-operations (RPC authorization failures), denied-data-writes (datastore write denials), and denied-notifications (notifications dropped due to access denial). All are yang:zero-based-counter32 values.
This document registers URI 'urn:ietf:params:xml:ns:yang:ietf-netconf-acm' in the IETF XML Registry (RFC 3688), and registers module name 'ietf-netconf-acm' with prefix 'nacm' in the YANG Module Names registry (RFC 6020).
A session can perform a denial-of-service attack by locking the datastore without requiring write access, using <lock>, <unlock>, <partial-lock>, or <partial-unlock>. Administrators may wish to explicitly restrict exec access to these operations in NACM rules.
'Fishing' attacks allow a session with some write access but no read access to a sensitive subtree to determine the presence or absence of sensitive data by repeatedly issuing edit requests and observing whether access-denied errors are returned, even without the error-path field being present in the response.
When external group names from the transport layer (e.g., RADIUS) are used and the transport does not protect against man-in-the-middle attacks, an attacker could inject group names configured in NACM, granting a user more permissions than intended. Administrators should set /nacm/enable-external-groups to 'false' when using such protocols.
Data node access authorization is a 12-step ordered procedure: permit if NACM disabled or recovery session; collect user's groups; match ordered rule-lists and rules on module-name, data-node path, and CRUDX access-operations bits; apply action; check nacm:default-deny-all (for read/write) and nacm:default-deny-write (for write); apply read-default or write-default fallback. Denied reads silently omit the node from the reply.
Incoming RPC authorization is a 12-step ordered procedure: (1) permit if NACM disabled; (2) permit if recovery session; (3) permit close-session; (4) collect user's groups; (5-8) match ordered rule-lists and rules on module-name, rule-type (protocol-operation), and exec access-operations bit; (9) no rule found; (10) deny if default-deny-all present; (11) deny kill-session or delete-config; (12) apply exec-default fallback.
Outgoing notification authorization is an 11-step procedure: permit if NACM disabled or recovery session; permit replayComplete/notificationComplete events; collect user's groups; match ordered rule-lists and notification rules on module-name, notification-name, and read access-operations bit; apply action (drop notification if denied); check default-deny-all; apply read-default fallback.