Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8341

Network Configuration Access Control Model

Pages: 58
Internet Standard: 91
Errata
Obsoletes:  6536
Part 1 of 3 – Pages 1 to 13
None   None   Next

Top   ToC   RFC8341 - Page 1
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 Model

Abstract

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.
Top   ToC   RFC8341 - Page 2
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
Top   ToC   RFC8341 - Page 3
      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
Top   ToC   RFC8341 - Page 4

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
Top   ToC   RFC8341 - Page 5
   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.
Top   ToC   RFC8341 - Page 6
   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).
Top   ToC   RFC8341 - Page 7
   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
Top   ToC   RFC8341 - Page 8

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.
Top   ToC   RFC8341 - Page 9

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.
Top   ToC   RFC8341 - Page 10
   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.
Top   ToC   RFC8341 - Page 11
   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.
Top   ToC   RFC8341 - Page 12
                    +-------------------------+
                    |       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
Top   ToC   RFC8341 - Page 13
   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)

Next Section