RFC 8341
Network Configuration Access Control Model
Internet Engineering Task Force (IETF) A. Bierman Request for Comments: 8341 YumaWorks STD: 91 M. Bjorklund Obsoletes: 6536 Tail-f Systems Category: Standards Track March 2018 ISSN: 2070-1721 Network Configuration Access Control ModelAbstract
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8341.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................4 1.1. Terminology ................................................4 1.2. Changes since RFC 6536 .....................................6 2. Access Control Design Objectives ................................7 2.1. Access Control Points ......................................7 2.2. Simplicity .................................................8 2.3. Procedural Interface .......................................8 2.4. Datastore Access ...........................................8 2.5. Users and Groups ...........................................8 2.6. Maintenance ................................................9 2.7. Configuration Capabilities .................................9 2.8. Identifying Security-Sensitive Content .....................9 3. NETCONF Access Control Model (NACM) ............................10 3.1. Overview ..................................................10 3.1.1. Features ...........................................10 3.1.2. External Dependencies ..............................11 3.1.3. Message Processing Model ...........................11 3.2. Datastore Access ..........................................14 3.2.1. Mapping New Datastores to NACM .....................14 3.2.2. Access Rights ......................................14 3.2.3. RESTCONF Methods ...................................15 3.2.4. <get> and <get-config> Operations ..................16 3.2.5. <edit-config> Operation ............................16 3.2.6. <copy-config> Operation ............................18 3.2.7. <delete-config> Operation ..........................18 3.2.8. <commit> Operation .................................19 3.2.9. <discard-changes> Operation ........................19 3.2.10. <kill-session> Operation ..........................19
3.3. Model Components ..........................................19
3.3.1. Users ..............................................19
3.3.2. Groups .............................................20
3.3.3. Emergency Recovery Session .........................20
3.3.4. Global Enforcement Controls ........................20
3.3.4.1. enable-nacm Switch ........................20
3.3.4.2. read-default Switch .......................20
3.3.4.3. write-default Switch ......................21
3.3.4.4. exec-default Switch .......................21
3.3.4.5. enable-external-groups Switch .............22
3.3.5. Access Control Rules ...............................22
3.4. Access Control Enforcement Procedures .....................22
3.4.1. Initial Operation ..................................23
3.4.2. Session Establishment ..............................23
3.4.3. "access-denied" Error Handling .....................23
3.4.4. Incoming RPC Message Validation ....................24
3.4.5. Data Node Access Validation ........................26
3.4.6. Outgoing <notification> Authorization ..............29
3.5. Data Model Definitions ....................................31
3.5.1. Data Organization ..................................31
3.5.2. YANG Module ........................................32
4. IANA Considerations ............................................42
5. Security Considerations ........................................42
5.1. NACM Configuration and Monitoring Considerations ..........43
5.2. General Configuration Issues ..............................45
5.3. Data Model Design Considerations ..........................47
6. References .....................................................47
6.1. Normative References ......................................47
6.2. Informative References ....................................49
Appendix A. Usage Examples ........................................50
A.1. <groups> Example ...........................................50
A.2. Module Rule Example ........................................51
A.3. Protocol Operation Rule Example ............................53
A.4. Data Node Rule Example .....................................55
A.5. Notification Rule Example ..................................57
Authors' Addresses ................................................58
1. Introduction
The Network Configuration Protocol (NETCONF) and the RESTCONF protocol do not provide any standard mechanisms to restrict the protocol operations and content that each user is authorized to access. There is a need for interoperable management of the controlled access to administrator-selected portions of the available NETCONF or RESTCONF content within a particular server. This document addresses access control mechanisms for the Operations and Content layers of NETCONF, as defined in [RFC6241]; and RESTCONF, as defined in [RFC8040]. It contains three main sections: 1. Access Control Design Objectives 2. NETCONF Access Control Model (NACM) 3. YANG Data Model (ietf-netconf-acm.yang) YANG version 1.1 [RFC7950] adds two new constructs that need special access control handling. The "action" statement is similar to the "rpc" statement, except that it is located within a data node. The "notification" statement can also be located within a data node.1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are defined in [RFC8342] and are not redefined here: o datastore o configuration datastore o conventional configuration datastore o candidate configuration datastore o running configuration datastore o startup configuration datastore
o operational state datastore o client o server The following terms are defined in [RFC6241] and are not redefined here: o protocol operation o session o user The following terms are defined in [RFC7950] and are not redefined here: o action o data node o data definition statement The following terms are defined in [RFC8040] and are not redefined here: o data resource o datastore resource o operation resource o target resource The following term is defined in [RFC7230] and is not redefined here: o request URI The following terms are used throughout this document: access control: A security feature provided by the server that allows an administrator to restrict access to a subset of all protocol operations and data, based on various criteria. access control model (ACM): A conceptual model used to configure and monitor the access control procedures desired by the administrator to enforce a particular access control policy.
access control rule: The criterion used to determine if a particular
access operation will be permitted or denied.
access operation: How a request attempts to access a conceptual
object. One of "none", "read", "create", "delete", "update", or
"execute".
data node hierarchy: The hierarchy of data nodes that identifies the
specific "action" or "notification" node in the datastore.
recovery session: A special administrative session that is given
unlimited NETCONF access and is exempt from all access control
enforcement. The mechanism or mechanisms used by a server to
control and identify whether or not a session is a recovery
session are implementation specific and are outside the scope of
this document.
write access: A shorthand for the "create", "delete", and "update"
access operations.
1.2. Changes since RFC 6536
The NACM procedures and data model have been updated to support new
data modeling capabilities in version 1.1 of the YANG data modeling
language. The "action" and "notification" statements can be used
within data nodes to define data-model-specific operations and
notifications.
An important use case for these new YANG statements is the increased
access control granularity that can be achieved over top-level "rpc"
and "notification" statements. The new "action" and "notification"
statements are used within data nodes, and access to the action or
notification can be restricted to specific instances of these data
nodes.
Support for the RESTCONF protocol has been added. The RESTCONF
operations are similar to the NETCONF operations, so a simple mapping
to the existing NACM procedures and data model is possible.
The data node access behavior for path matches has been clarified to
also include matching descendant nodes of the specified path.
The <edit-config> operation access rights behavior has been clarified
to indicate that write access is not required for data nodes that are
implicitly modified through side effects (such as the evaluation of
YANG when-stmts, or data nodes implicitly deleted when creating a
data node under a different branch under a YANG choice-stmt).
The Security Considerations section has been updated to comply with the "YANG module security guidelines" [YANG-SEC]. Note that the YANG module in this document does not define any RPC operations.2. Access Control Design Objectives
This section documents the design objectives for the NETCONF access control model presented in Section 3.2.1. Access Control Points
NETCONF allows server implementers to add new custom protocol operations, and the YANG data modeling language supports this feature. These operations can be defined in standard or proprietary YANG modules. It is not possible to design an ACM for NETCONF that only focuses on a static set of standard protocol operations defined by NETCONF itself, like some other protocols. Since few assumptions can be made about an arbitrary protocol operation, the NETCONF architectural server components need to be protected at three conceptual control points. These access control points, described in Figure 1, are as follows: protocol operation: Permission to invoke specific protocol operations. datastore: Permission to read and/or alter specific data nodes within any datastore. notification: Permission to receive specific notification event types. +-------------+ +-------------+ client | protocol | | data node | request --> | operation | -------------> | access | | allowed? | datastore | allowed? | +-------------+ or state +-------------+ data access +----------------+ | notification | event --> | allowed? | +----------------+ Figure 1
2.2. Simplicity
There is concern that a complicated ACM will not be widely deployed because it is too hard to use. Configuration of the access control system needs to be as simple as possible. Simple and common tasks need to be easy to configure and require little expertise or domain-specific knowledge. Complex tasks are possible using additional mechanisms that may require additional expertise. A single set of access control rules ought to be able to control all types of NETCONF protocol operation invocation, all datastore access, and all notification events. Access control ought to be defined with a small and familiar set of permissions, while still allowing full control of datastore access.2.3. Procedural Interface
NETCONF uses a Remote Procedure Call (RPC) model and an extensible set of protocol operations. Access control for any possible protocol operation is necessary.2.4. Datastore Access
It is necessary to control access to specific nodes and subtrees within the datastore, regardless of which protocol operation -- standard or proprietary -- was used to access the datastore.2.5. Users and Groups
It is necessary that access control rules for a single user or a configurable group of users can be configured. The ACM needs to support the concept of administrative groups, to support the well-established distinction between a root account and other types of less-privileged conceptual user accounts. These groups need to be configurable by the administrator. It is necessary that the user-to-group mapping can be delegated to a central server, such as a RADIUS server [RFC2865] [RFC5607]. Since authentication is performed by the transport layer and RADIUS performs authentication and service authorization at the same time, the underlying transport protocol needs to be able to report a set of group names associated with the user to the server. It is necessary that the administrator can disable the usage of these group names within the ACM.
2.6. Maintenance
It ought to be possible to disable part or all of the access control model enforcement procedures without deleting any access control rules.2.7. Configuration Capabilities
Suitable configuration and monitoring mechanisms are needed to allow an administrator to easily manage all aspects of the ACM's behavior. A standard data model, suitable for use with the <edit-config> protocol operation, needs to be available for this purpose. Access control rules to restrict access operations on specific subtrees within the configuration datastore need to be supported.2.8. Identifying Security-Sensitive Content
One of the most important aspects of the data model documentation, and one of the biggest concerns during deployment, is the identification of security-sensitive content. This applies to protocol operations in NETCONF, not just data and notifications. It is mandatory for security-sensitive objects to be documented in the Security Considerations section of an RFC. This is nice, but it is not good enough, for the following reasons: o This documentation-only approach forces administrators to study the RFC and determine if there are any potential security risks introduced by a new data model. o If any security risks are identified, then the administrator must study some more RFC text and determine how to mitigate the security risk(s). o The ACM on each server must be configured to mitigate the security risks, e.g., require privileged access to read or write the specific data identified in the Security Considerations section. o If the ACM is not preconfigured, then there will be a time window of vulnerability after the new data model is loaded and before the new access control rules for that data model are configured, enabled, and debugged. Often, the administrator just wants to disable default access to the secure content so that no inadvertent or malicious changes can be made to the server. This allows the default rules to be more lenient, without significantly increasing the security risk.
A data model designer needs to be able to use machine-readable statements to identify content that needs to be protected by default. This will allow client and server tools to automatically identify data-model-specific security risks, by denying access to sensitive data unless the user is explicitly authorized to perform the requested access operation.3. NETCONF Access Control Model (NACM)
3.1. 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.3.1.1. Features
The NACM data model provides the following features: o Independent control of RPC, action, data, and notification access is provided. o 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. o A simple and familiar set of datastore permissions is used. o Support for YANG security tagging (e.g., a "nacm:default-deny-write" statement) allows default security modes to automatically exclude sensitive data. o Separate default access modes for read, write, and execute permissions are provided. o Access control rules are applied to configurable groups of users. o The access control enforcement procedures can be disabled during operation, without deleting any access control rules, in order to debug operational problems.
o The number of denied protocol operation requests and denied
datastore write requests can be monitored by the client.
o Simple unconstrained YANG instance-identifiers are used to
configure access control rules for specific data nodes.
3.1.2. External Dependencies
NETCONF [RFC6241] and RESTCONF [RFC8040] are used for network
management purposes within this document.
The YANG data modeling language [RFC7950] is used to define the data
models for use with NETCONF or RESTCONF. YANG is also used to define
the data model in this document.
3.1.3. Message Processing Model
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.
The new "pre-read data node acc. ctl" boxes in the diagram below
refer to group read access as it relates to data node ancestors of an
action or notification. As an example, if an action is defined as
/interfaces/interface/reset-interface, the group must be authorized
to (1) read /interfaces and /interfaces/interface and (2) execute on
/interfaces/interface/reset-interface.
+-------------------------+ | session | | (username) | +-------------------------+ | ^ V | +--------------+ +---------------+ | message | | message | | dispatcher | | generator | +--------------+ +---------------+ | | ^ ^ | V | | | +=============+ | | | | pre-read | | | | | data node | | | | | acc. ctl | | | | +=============+ | | | | | | V V | | +===========+ +-------------+ +----------------+ | operation |---> | reply | | <notification> | | acc. ctl | | generator | | generator | +===========+ +-------------+ +----------------+ | ^ ^ ^ V +------+ | | +-----------+ | +=============+ +================+ | operation | | | read | | <notification> | | 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 | | | <--- | | +---------------+ +-------------------+ Figure 2
The following high-level sequence of conceptual processing steps is
executed for each received <rpc> message, if access control
enforcement is enabled:
o 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.
o If the <action> operation defined in [RFC7950] 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.
o Otherwise, if the user is not authorized to execute the specified
protocol operation, then the request is rejected with an
"access-denied" error.
o If a datastore is accessed by the protocol operation, then the
server checks to see 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:
o Server instrumentation generates a notification for a particular
subscription.
o If the "notification" statement is specified within a data
subtree, as specified in [RFC7950], 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.
o 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.
(next page on part 2)
