Network Configuration Protocol (NETCONF) Access Control Model

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.

The NACM data model provides the following features: Independent control of RPC, data, and notification access. Simple access control rules configuration data model that is easy to use. 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. A simple and familiar set of datastore permissions is used. Support for YANG security tagging (e.g., "nacm:default-deny-write" statement) allows default security modes to automatically exclude sensitive data. Separate default access modes for read, write, and execute permissions. Access control rules are applied to configurable groups of users. The entire ACM can be disabled during operation, in order to debug operational problems. Access control rules are simple to configure. The number of denied protocol operation requests and denied datastore write requests can be monitored by the client. Simple unconstrained YANG instance identifiers are used to configure access control rules for specific data nodes.

The NETCONF protocol is used for all management purposes within this document. It is expected that the mandatory transport mapping NETCONF Over SSH is also supported by the server, and that the server has access to the user name associated with each session. The YANG Data Modeling Language is used to define the NETCONF data models specified in this document.

The following diagram shows the conceptual message flow model, including the points at which access control is applied, during NETCONF message processing.

|---> | | | | | acc. ctl | | generator | | generator | +===========+ +-------------+ +----------------+ | ^ ^ ^ V +------+ | | +-----------+ | +=============+ +================+ | | | | read | | | | processor |-+ | data node | | access ctl | | | | acc. ctl | | | +-----------+ +=============+ +================+ | | ^ ^ V +----------------+ | | +===========+ | | | | write | | | | | data node | | | | | acc. ctl | -----------+ | | | +===========+ | | | | | | | | | V V V | | +---------------+ +-----------------+ | configuration | ---> | server | | datastore | | instrumentation | | | <--- | | +---------------+ +-----------------+ ]]> The following high-level sequence of conceptual processing steps is executed for each received <rpc> message, if access control enforcement is enabled: Access control is applied to all <rpc> messages (except <close-session>) received by the server, individually, for each active session, unless the session is identified as a "recovery session". If the user is authorized to execute the specified protocol operation, then processing continues, otherwise the request is rejected with an "access-denied" error. If the configuration datastore or conceptual state data is accessed by the protocol operation, then the data node access MUST be authorized. If the user is authorized to perform the requested access operation on the requested data, then processing continues. The following sequence of conceptual processing steps is executed for each generated notification event, if access control enforcement is enabled: Server instrumentation generates a notification, for a particular subscription. The notification access control enforcer checks the notification event type, and if it is one which the user is not authorized to read, then the notification is dropped for that subscription.

The same access control rules apply to all datastores. For example, the candidate configuration datastore or the running configuration datastore. Only the standard NETCONF datastores (candidate, running, and startup) are controlled by the ACM. Local or remote files or datastores accessed via the <url> parameter are optional to support.

A small set of hard-wired datastore access rights is needed to control access to all possible NETCONF protocol operations, including vendor extensions to the standard protocol operation set. The "CRUDX" model can support all NETCONF protocol operations: Create: Allows the client to add a new data node instance to a datastore. Read: Allows the client to read a data node instance from a datastore, or receive the notification event type. Update: Allows the client to update an existing data node instance in a datastore. Delete: Allows the client to delete a data node instance from a datastore. eXec: Allows the client to execute the protocol operation.

Data nodes to which the client does not have read access are silently omitted from the <rpc-reply> message. This is done to allow NETCONF filters for <get> and <get-config> to function properly, instead of causing an "access-denied" error because the filter criteria would otherwise include unauthorized read access to some data nodes. For NETCONF filtering purposes, the selection criteria is applied to the subset of nodes that the user is authorized to read, not the entire datastore.

The NACM access rights are not directly coupled to the <edit-config> "operation" attribute, although they are similar. Instead, a NACM access right applies to all protocol operations which would result in a particular access operation to the target datastore. This section describes how these access rights apply to the specific access operations supported by the <edit-config> protocol operation. If the effective access operation is "none" (i.e., default-operation="none") for a particular data node, then no access control is applied to that data node. If the protocol operation would result in the creation of a data store node, and the user does not have "create" access permission for that node, the protocol operation is rejected with an "access-denied" error. If the protocol operation would result in the deletion of a data store node, and the user does not have "delete" access permission for that node, the protocol operation is rejected with an "access-denied" error. If the protocol operation would result in the modification of a data store node, and the user does not have "update" access permission for that node, the protocol operation is rejected with an "access-denied" error. A "merge" or "replace" <edit-config> operation may include data nodes which do not alter portions of the existing datastore. For example, a container or list node may be present for naming purposes, but does not actually alter the corresponding datastore node. These unaltered data nodes are ignored by the server, and do not require any access rights by the client. A "merge" <edit-config> operation may include data nodes, but not include particular child data nodes that are present in the datastore. These missing data nodes within the scope of a "merge" <edit-config> operation are ignored by the server, and do not require any access rights by the client. The contents of specific restricted datastore nodes MUST NOT be exposed in any <rpc-error> elements within the reply.

Access control for the <copy-config> protocol operation requires special consideration because the administrator may be replacing the entire target datastore. If the source of the <copy-config> protocol operation is the running configuration datastore, and the target is the startup configuration datastore, the client is only required to have permission to execute the <copy-config> protocol operation. Otherwise: If the source of the <copy-config> operation is a datastore, then data nodes to which the client does not have read access are silently omitted. If the target of the <copy-config> operation is a datastore, the client needs access to the modified nodes. Specifically: If the protocol operation would result in the creation of a data store node, and the user does not have "create" access permission for that node, the protocol operation is rejected with an "access-denied" error. If the protocol operation would result in the deletion of a data store node, and the user does not have "delete" access permission for that node, the protocol operation is rejected with an "access-denied" error. If the protocol operation would result in the modification of a data store node, and the user does not have "update" access permission for that node, the protocol operation is rejected with an "access-denied" error.

Access to the <delete-config> protocol operation is denied by default. The 'exec-default' parameter does not apply to this protocol operation. Access control rules must be explicitly configured to allow invocation by a non-recovery session.

The server MUST determine the exact nodes in the running configuration datastore which are actually different, and only check "create", "update", and "delete" access permissions for this set of nodes, which could be empty. For example, if a session can read the entire datastore, but only change one leaf, that session needs to be able to edit and commit that one leaf.

The client is only required to have permission to execute the <discard-changes> protocol operation. No datastore permissions are needed.

The <kill-session> operation does not directly alter a datastore. However, it allows one session to disrupt another session which is editing a datastore. Access to the <kill-session> protocol operation is denied by default. The 'exec-default' parameter does not apply to this protocol operation. Access control rules must be explicitly configured to allow invocation by a non-recovery session.

This section defines the conceptual components related to access control model.

A "user" is the conceptual entity that is associated with the access permissions granted to a particular session. A user is identified by a string which is unique within the server. As described in , the user name string is derived from the transport layer during session establishment. If the transport layer cannot authenticate the user, the session is terminated. The server MAY support a "recovery session" mechanism, which will bypass all access control enforcement. This is useful for restricting initial access and repairing a broken access control configuration.

Access to a specific NETCONF protocol operation is granted to a session, associated with a group, not a user. A group is identified by its name. All group names are unique within the server. A group member is identified by a user name string. The same user can be a member of multiple groups.

There are four global controls that are used to help control how access control is enforced.

A global "enable-nacm" on/off switch is provided to enable or disable all access control enforcement. When this global switch is set to "true", then all requests are checked against the access control rules, and only permitted if configured to allow the specific access request. When this global switch is set to "false", then all access requested are permitted.

An on/off "read-default" switch is provided to enable or disable default access to receive data in replies and notifications. When the "enable-nacm" global switch is set to "true", then this global switch is relevant, if no matching access control rule is found to explicitly permit or deny read access to the requested NETCONF datastore data or notification event type. When this global switch is set to "permit", and no matching access control rule is found for the NETCONF datastore read or notification event requested, then access is permitted. When this global switch is set to "deny", and no matching access control rule is found for the NETCONF datastore read or notification event requested, then access is denied.

An on/off "write-default" switch is provided to enable or disable default access to alter configuration data. When the "enable-nacm" global switch is set to "true", then this global switch is relevant, if no matching access control rule is found to explicitly permit or deny write access to the requested NETCONF datastore data. When this global switch is set to "permit", and no matching access control rule is found for the NETCONF datastore write requested, then access is permitted. When this global switch is set to "deny", and no matching access control rule is found for the NETCONF datastore write requested, then access is denied.

An on/off "exec-default" switch is provided to enable or disable default access to execute protocol operations. When the "enable-nacm" global switch is set to "true", then this global switch is relevant, if no matching access control rule is found to explicitly permit or deny access to the requested NETCONF protocol operation. When this global switch is set to "permit", and no matching access control rule is found for the NETCONF protocol operation requested, then access is permitted. When this global switch is set to "deny", and no matching access control rule is found for the NETCONF protocol operation requested, then access is denied.

There are 4 types of rules available in NACM: Controls access for definitions in a specific YANG module, identified by its name. Controls access for a specific protocol operation, identified by its YANG module and name. Controls access for a specific data node, identified by its path location within the conceptual XML document for the data node. Controls access for a specific notification event type, identified by its YANG module and name.

There are seven separate phases that need to be addressed, four of which are related to the NETCONF message processing model. In addition, the initial start-up mode for a NETCONF server, session establishment, and "access-denied" error handling procedures also need to be considered. The server MUST use the access control rules in effect at the time it starts processing the message. The same access control rules MUST stay in effect for the processing of the entire message.

Upon the very first start-up of the NETCONF server, the access control configuration will probably not be present. If it isn't, a server MUST NOT allow any write access to any session role except a "recovery session". Access rules are enforced any time a request is initiated from a user session. Access control is not enforced for server-initiated access requests, such as the initial load of the running datastore, during bootup.

The access control model applies specifically to the well-formed XML content transferred between a client and a server, after session establishment has been completed, and after the <hello> exchange has been successfully completed. Once session establishment is completed, and a user has been authenticated, the NETCONF transport layer reports the user name and a possibly empty set of group names associated with the user to the NETCONF server. The NETCONF server will enforce the access control rules, based on the supplied user name, group names, and the configuration data stored on the server.

The "access-denied" error-tag is generated when the access control system denies access to either a request to invoke a protocol operation or a request to perform a particular access operation on the configuration datastore. A server MUST NOT include any sensitive information in any <error-info> elements within the <rpc-error> response.

The diagram below shows the basic conceptual structure of the access control processing model for incoming NETCONF <rpc> messages, within a server.

| +------------+ | | | | | +-------------------------+ | +------------+ | V V V +-----------+ +---------------+ +------------+ | acme NS | | NC-base NS | | NC-base NS | | | | | | | +-----------+ +---------------+ +------------+ | | | | V V +----------------------+ | | | configuration | | datastore | +----------------------+ ]]> Access control begins with the message dispatcher. After the server validates the <rpc> element, and determines the namespace URI and the element name of the protocol operation being requested, the server verifies that the user is authorized to invoke the protocol operation. The protocol operation is authorized by following these steps: If the "enable-nacm" leaf is set to "false", then the protocol operation is permitted. If the requesting session is identified as a "recovery session", then the protocol operation is permitted. If the requested operation is the NETCONF <close-session> protocol operation, then the protocol operation is permitted. Check all the "group" entries for ones that contain a "user-name" entry that equals the user name for the session making the request. Add to these groups the set of groups provided by the transport layer. If no groups are found, continue with step 10. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met: The rule's "module-name" leaf is "*", or equals the name of the YANG module where the protocol operation is defined. The rule does not have a "rule-type" defined, or the "rule-type" is "protocol-operation" and the "rpc-name" is "*" or equals the name of the requested protocol operation. The rule's "access-operations" leaf has the "exec" bit set, or has the special value "*". If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then the protocol operation is permitted, otherwise it is denied. Otherwise, no matching rule was found in any rule-list entry. If the requested protocol operation is defined in a YANG module advertised in the server capabilities, and the "rpc" statement contains a "nacm:default-deny-all" statement, then the protocol operation is denied. If the requested protocol operation is the NETCONF <kill-session> or <delete-config>, then the protocol operation is denied. If the "exec-default" leaf is set to "permit", then permit the protocol operation, otherwise deny the request. If the user is not authorized to invoke the protocol operation then an <rpc-error> is generated with the following information: access-denied Identifies the requested protocol operation. For example:

/nc:rpc/nc:edit-config ]]> represents the <edit-config> protocol operation in the NETCONF base namespace. If a datastore is accessed, either directly or as a side effect of the protocol operation, then the server MUST intercept the access operation and make sure the user is authorized to perform the requested access operation on the specified data, as defined in .

If a data node within a datastore is accessed, then the server MUST ensure that the user is authorized to perform the requested read, create, update, or delete access operation on the specified data node. The data node access request is authorized by following these steps: If the "enable-nacm" leaf is set to "false", then the access operation is permitted. If the requesting session is identified as a "recovery session", then the access operation is permitted. Check all the "group" entries for ones that contain a "user-name" entry that equals the user name for the session making the request. Add to these groups the set of groups provided by the transport layer. If no groups are found, continue with step 9. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met: The rule's "module-name" leaf is "*", or equals the name of the YANG module where the requested data node is defined. The rule does not have a "rule-type" defined, or the "rule-type" is "data-node" and the "path" matches the requested data node. For a read access operation, the rule's "access-operations" leaf has the "read" bit set, or has the special value "*". For a create access operation, the rule's "access-operations" leaf has the "create" bit set, or has the special value "*". For a delete access operation, the rule's "access-operations" leaf has the "delete" bit set, or has the special value "*". For an update access operation, the rule's "access-operations" leaf has the "update" bit set, or has the special value "*". If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then the data node access is permitted, otherwise it is denied. For a read access operation, "denied" means that the requested data is not returned in the reply. Otherwise, no matching rule was found in any rule-list entry. For a read access operation, if the requested data node is defined in a YANG module advertised in the server capabilities, and the data definition statement contains a "nacm:default-deny-all" statement, then the requested data node is not included in the reply. For a write access operation, if the requested data node is defined in a YANG module advertised in the server capabilities, and the data definition statement contains a "nacm:default-deny-write" or a "nacm:default-deny-all" statement, then the data node access request is denied. For a read access operation, if the "read-default" leaf is set to "permit", then include the requested data node in the reply, otherwise do not include the requested data node in the reply. For a write access operation, if the "write-default" leaf is set to "permit", then permit the data node access request, otherwise deny the request.

Configuration of access control rules specifically for descendant nodes of the notification event type element are outside the scope of this document. If the user is authorized to receive the notification event type, then it is also authorized to receive any data it contains. The following figure shows the conceptual message processing model for outgoing <notification> messages.

| | generator | +----------------+ ^ | +=================+ | | | access control | | | +=================+ ^ | +------------------------+ | server instrumentation | +------------------------+ | ^ V | +----------------------+ | configuration | | datastore | +----------------------+ ]]> The generation of a notification for a specific subscription is authorized by following these steps: If the "enable-nacm" leaf is set to "false", then the notification is permitted. If the session is identified as a "recovery session", then the notification is permitted. If the notification is the NETCONF <replayComplete> or <notificationComplete> event type , then the notification is permitted. Check all the "group" entries for ones that contain a "user-name" entry that equals the user name for the session making the request. Add to these groups the set of groups provided by the transport layer. If no groups are found, continue with step 10. Process all rule-list entries, in the order they appear in the configuration. If a rule-list's "group" leaf-list does not match any of the user's groups, proceed to the next rule-list entry. For each rule-list entry found, process all rules, in order, until a rule that matches the requested access operation is found. A rule matches if all of the following criteria are met: The rule's "module-name" leaf is "*", or equals the name of the YANG module where the notification is defined. The rule does not have a "rule-type" defined, or the "rule-type" is "notification" and the "notification-name" is "*", equals the name of the notification. The rule's "access-operations" leaf has the "read" bit set, or has the special value "*". If a matching rule is found, then the "action" leaf is checked. If it is equal to "permit", then permit the notification, otherwise drop the notification for the associated subscription. Otherwise, no matching rule was found in any rule-list entry. If the requested notification is defined in a YANG module advertised in the server capabilities, and the "notification" statement contains a "nacm:default-deny-all" statement, then the notification is dropped for the associated subscription. If the "read-default" leaf is set to "permit", then permit the notification, otherwise drop the notification for the associated subscription.

This section defines the semantics of the conceptual data structures found in the data model in .

The following diagram highlights the contents and structure of the NACM YANG module.

The following YANG module specifies the normative NETCONF content that MUST by supported by the server. The "ietf-netconf-acm" YANG module imports typedefs from .

file="ietf-netconf-acm@2011-10-04.yang" module ietf-netconf-acm { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm"; prefix "nacm"; import ietf-yang-types { prefix yang; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: WG Chair: Mehmet Ersue WG Chair: Bert Wijnen Editor: Andy Bierman Editor: Martin Bjorklund "; description "NETCONF Access Control Model. Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and // remove this note // RFC Ed.: remove this note // Note: extracted from draft-ietf-netconf-access-control-05.txt // RFC Ed.: please update the date to the date of publication revision "2011-10-04" { description "Initial version"; reference "RFC XXXX: Network Configuration Protocol Access Control Model"; } /* * Extension statements */ extension default-deny-write { description "Used to indicate that the data model node represents a sensitive security system parameter. If present, and the NACM module is enabled (i.e., /nacm/enable-nacm object equals 'true'), the NETCONF server will only allow the designated 'recovery session' to have write access to the node. An explicit access control rule is required for all other users. The 'default-deny-write' extension MAY appear within a data definition statement. It is ignored otherwise."; } extension default-deny-all { description "Used to indicate that the data model node controls a very sensitive security system parameter. If present, and the NACM module is enabled (i.e., /nacm/enable-nacm object equals 'true'), the NETCONF server will only allow the designated 'recovery session' to have read, write, or execute access to the node. An explicit access control rule is required for all other users. The 'default-deny-all' extension MAY appear within a data definition statement, 'rpc' statement, or 'notification' statement. It is ignored otherwise."; } /* * Derived types */ typedef user-name-type { type string { length "1..max"; } description "General Purpose User Name string."; } typedef matchall-string-type { type string { pattern "\*"; } description "The string containing a single asterisk '*' is used to conceptually represent all possible values for the particular leaf using this data type."; } typedef access-operations-type { type bits { bit create { description "Any protocol operation that creates a new data node."; } bit read { description "Any protocol operation or notification that returns the value of a data node."; } bit update { description "Any protocol operation that alters an existing data node."; } bit delete { description "Any protocol operation that removes a data node."; } bit exec { description "Execution access to the specified protocol operation."; } } description "NETCONF Access Operation."; } typedef group-name-type { type string { length "1..max"; pattern "[^\*].*"; } description "Name of administrative group to which users can be assigned."; } typedef action-type { type enumeration { enum permit { description "Requested action is permitted."; } enum deny { description "Requested action is denied."; } } description "Action taken by the server when a particular rule matches."; } typedef node-instance-identifier { type yang:xpath1.0; description "Path expression used to represent a special data node instance identifier string. A node-instance-identifier value is an unrestricted YANG instance-identifier expression. All the same rules as an instance-identifier apply except predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key. This XPath expression is evaluated in the following context: o The set of namespace declarations are those in scope on the leaf element where this type is used. o The set of variable bindings contains one variable, 'USER', which contains the name of user of the current session. o The function library is the core function library, but note that due to the syntax restrictions of an instance-identifier, no functions are allowed. o The context node is the root node in the data tree."; } container nacm { nacm:default-deny-all; description "Parameters for NETCONF Access Control Model."; leaf enable-nacm { type boolean; default true; description "Enable or disable all NETCONF access control enforcement. If 'true', then enforcement is enabled. If 'false', then enforcement is disabled."; } leaf read-default { type action-type; default "permit"; description "Controls whether read access is granted if no appropriate rule is found for a particular read request."; } leaf write-default { type action-type; default "deny"; description "Controls whether create, update, or delete access is granted if no appropriate rule is found for a particular write request."; } leaf exec-default { type action-type; default "permit"; description "Controls whether exec access is granted if no appropriate rule is found for a particular protocol operation request."; } leaf denied-operations { type yang:zero-based-counter32; config false; mandatory true; description "Number of times a protocol operation request was denied since the server last restarted."; } leaf denied-data-writes { type yang:zero-based-counter32; config false; mandatory true; description "Number of times a protocol operation request to alter a configuration datastore was denied, since the server last restarted."; } leaf denied-notifications { type yang:zero-based-counter32; config false; mandatory true; description "Number of times a notification was dropped for a subscription because access to the event type was denied, since the server last restarted."; } container groups { description "NETCONF Access Control Groups."; list group { key name; description "One NACM Group Entry."; leaf name { type group-name-type; description "Group name associated with this entry."; } leaf-list user-name { type user-name-type; description "Each entry identifies the user name of a member of the group associated with this entry."; } } } list rule-list { key "name"; ordered-by user; description "An ordered collection of access control rules."; leaf name { type string { length "1..max"; } description "Arbitrary name assigned to the rule-list."; } leaf-list group { type union { type matchall-string-type; type group-name-type; } description "List of administrative groups that will be assigned the associated access rights defined by the 'rule' list. The string '*' indicates that all groups apply to the entry."; } list rule { key "name"; ordered-by user; description "One access control rule. Rules are processed in user-defined order until a match is found. A rule matches if 'module-name', 'rule-type', and 'access-operations' matches the request. If a rule matches, the 'action' leaf determines if access is granted or not."; leaf name { type string { length "1..max"; } description "Arbitrary name assigned to the rule."; } leaf module-name { type union { type matchall-string-type; type string; } default "*"; description "Name of the module associated with this rule. This leaf matches if it has the value '*', or if the object being accessed is defined in the module with the specified module name."; } choice rule-type { description "This choice matches if all leafs present in the rule matches the request. If no leafs are present, the choice matches all requests."; case protocol-operation { leaf rpc-name { type union { type matchall-string-type; type string; } description "This leaf matches if it has the value '*', or if its value equals the requested protocol operation name."; } } case notification { leaf notification-name { type union { type matchall-string-type; type string; } description "This leaf matches if it has the value '*', or if its value equals the requested notification name."; } } case data-node { leaf path { type node-instance-identifier; mandatory true; description "Data Node Instance Identifier associated with the data node controlled by this rule. Configuration data or state data instance identifiers start with a top-level data node. A complete instance identifier is required for this type of path value. The special value '/' refers to all possible data store contents."; } } } leaf access-operations { type union { type matchall-string-type; type access-operations-type; } default "*"; description "Access operations associated with this rule. This leaf matches if it has the value '*', or if the bit corresponding to the requested operation is set."; } leaf action { type action-type; mandatory true; description "The access control action associated with the rule. If a rule is determined to match a particular request, then this object is used to determine whether to permit or deny the request."; } leaf comment { type string; description "A textual description of the access rule."; } } } } }

]]>



   
     
       There are two actions that are requested of IANA:
       This document registers one URI in "The IETF XML Registry".
       Following the format in , 
       the following has been registered.
     
     
       
         
       
     
     
       This document registers one module in the "YANG Module Names"
       registry.  Following the format in , 
       the following has been registered.

       
         
       
     
   

   
     
       This entire document discusses access control
       requirements and mechanisms for restricting
       NETCONF protocol behavior within a given session.
     
     
       This section highlights the issues for an administrator
       to consider when configuring a NETCONF server with NACM.
     
     
       
         Configuration of the access control system is
         highly sensitive to system security.  A server may
         choose not to allow any user configuration to
         some portions of it, such as the global security level,
         or the groups which allowed access to system resources.
       
       
         By default, NACM enforcement is enabled.
         By default, "read" access to all datastore contents enabled,
         (unless "nacm:default-deny-all" is specified for the data definition)
         and "exec" access is enabled for safe protocol operations.
         An administrator needs to ensure that NACM is enabled,
         and also decide if the default access parameters are 
         set appropriately.  Make sure the following data nodes
         are properly configured:
         
           /nacm/enable-nacm (default "true")
           /nacm/read-default (default "permit")
           /nacm/write-default (default "deny")
           /nacm/exec-default (default "permit")
         
       
       
         An administrator needs to restrict write access to all
         configurable objects within this data model.
       
       
         If write access is allowed for configuration of
         access control rules, then care needs to be taken
         not to disrupt the access control enforcement.
         For example, if the NACM access control rules are editing directly
         within the running configuration datastore (i.e.,
         :writable-running capability is supported and used),
         then care needs to be taken not to allow unintended
         access while the edits are being done.
       
       
         NACM requires some a user name in each NACM group
         mapping.  An administrator needs to make sure that
         the translation from a transport or implementation
         dependant user identity to a NACM user name is unique.
       
       
         An administrator needs to restrict read access to the
         following objects within this data model, which reveal
         access control configuration which could be considered
         sensitive.
         
           /nacm/enable-nacm
           /nacm/read-default
           /nacm/write-default
           /nacm/exec-default
           /nacm/groups
           /nacm/rule-list
         
       
     

     
       
         There is a risk that invocation of 
         non-standard protocol operations will have undocumented side effects.
         An administrator needs to construct access control rules
         such that the configuration datastore is protected
         from such side effects.
       
       
         It is possible for a session with some write access
         (e.g., allowed to invoke <edit-config>),
         but without any access to a particular datastore subtree
         containing sensitive data, to determine the presence
         or non-presence of that data.  
         This can be done by repeatedly issuing
         some sort of edit request (create, update, or delete)
         and possibly receiving "access-denied" errors in response.
         These "fishing" attacks can identify the presence or 
         non-presence of specific sensitive data even without 
         the "error-path" field being present within the "rpc-error"
         response.
       
       
         It is possible that the data model definition itself
         (e.g., YANG when-stmt) will help an unauthorized session
         determine the presence or even value of sensitive data nodes
         by examining the presence and values of different data nodes.
       
       
         There is a risk that non-standard protocol operations, or
         even the standard <get> protocol operation, may
         return data which "aliases" or "copies" sensitive data
         from a different data object.  There may simply be
         multiple data model definitions which expose
         or even configure the same underlying system
         instrumentation.
       
       
         A data model may contain external keys
         (e.g., YANG leafref), which expose values
         from a different data structure.
         An administrator needs to
         be aware of sensitive data models which contain leafref nodes.
         This entails finding all the leafref objects that
         "point" at the sensitive data (i.e., "path-stmt" values that 
         implicitly or explicitly include the sensitive data node.
       
       
         It is beyond the scope of this document to define access 
         control enforcement
         procedures for underlying device instrumentation that may
         exist to support the NETCONF server operation.  An administrator
         can identify each protocol operation that the server provides,
         and decide if it needs any access control applied to it.
       
       
         This document incorporates the optional use of a "recovery session"
         mechanism, which can be used to bypass access control
         enforcement in emergencies, such as NACM configuration errors
         which disable all access to the server. 
         The configuration and identification of such
         a recovery session mechanism are implementation-specific
         and outside the scope of this document.
         An administrator needs to be aware of any "recovery session"
         mechanisms available on the device, and make sure they
         are used appropriately.
       
       
         It is possible for a session to disrupt configuration
         management, even without any write access to the configuration,
         by locking the datastore. This may be done to insure all or 
         part of the configuration  remains stable while it is being
         retrieved, ot it may be done as a "denial-of-service" attack.
         There is no way for the server to know the difference.
         An administrator may wish to
         restrict "exec" access to the following protocol operations:
         
           <lock>
           <unlock>
           <partial-lock>
           <partial-unlock>
         
       
     
     
       
         Designers need to clearly identify any sensitive data,
         notifications, or protocol operations defined within a YANG
         module.  For such definitions, a "nacm:default-deny-write" or
         "nacm:default-deny-all" statement SHOULD be present, in
         addition to a clear description of the security risks.
       
       
         Protocol operations need to be properly documented by the
         data model designer, so it is clear to administrators what
         data nodes (if any) are affected by the protocol operation,
         and what information (if any) is returned in the
         <rpc-reply> message.
       
       
	 Data models ought to be designed so that different access
	 levels for input parameters to protocol operations is not required.
	 Use of generic protocol operations should be avoided, and separate
	 protocol operations defined instead, if different access levels 
	 are needed.