Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8341

STD 91
Pages: 58
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: NETCONF

Network Configuration Access Control Model

Part 1 of 3, p. 1 to 13
None       Next Section

Obsoletes:    6536


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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 Section