idnits 2.17.1 draft-ietf-netconf-rfc6536bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2017) is 2416 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-02 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Bierman 3 Internet-Draft YumaWorks 4 Obsoletes: 6536 (if approved) M. Bjorklund 5 Intended status: Standards Track Tail-f Systems 6 Expires: March 17, 2018 September 13, 2017 8 Network Configuration Protocol (NETCONF) Access Control Model 9 draft-ietf-netconf-rfc6536bis-05 11 Abstract 13 The standardization of network configuration interfaces for use with 14 the Network Configuration Protocol (NETCONF) or RESTCONF protocol 15 requires a structured and secure operating environment that promotes 16 human usability and multi-vendor interoperability. There is a need 17 for standard mechanisms to restrict NETCONF or RESTCONF protocol 18 access for particular users to a pre-configured subset of all 19 available NETCONF or RESTCONF protocol operations and content. This 20 document defines such an access control model. 22 This document obsoletes RFC 6536. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 17, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Changes Since RFC 6536 . . . . . . . . . . . . . . . . . 6 61 2. Access Control Design Objectives . . . . . . . . . . . . . . 6 62 2.1. Access Control Points . . . . . . . . . . . . . . . . . . 6 63 2.2. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3. Procedural Interface . . . . . . . . . . . . . . . . . . 7 65 2.4. Datastore Access . . . . . . . . . . . . . . . . . . . . 8 66 2.5. Users and Groups . . . . . . . . . . . . . . . . . . . . 8 67 2.6. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 8 68 2.7. Configuration Capabilities . . . . . . . . . . . . . . . 8 69 2.8. Identifying Security-Sensitive Content . . . . . . . . . 8 70 3. NETCONF Access Control Model (NACM) . . . . . . . . . . . . . 9 71 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.1. Features . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1.2. External Dependencies . . . . . . . . . . . . . . . . 10 74 3.1.3. Message Processing Model . . . . . . . . . . . . . . 11 75 3.2. Datastore Access . . . . . . . . . . . . . . . . . . . . 14 76 3.2.1. Mapping New Datastores to NACM . . . . . . . . . . . 14 77 3.2.2. Access Rights . . . . . . . . . . . . . . . . . . . . 14 78 3.2.3. RESTCONF Methods . . . . . . . . . . . . . . . . . . 15 79 3.2.4. and Operations . . . . . . . . . . 16 80 3.2.5. Operation . . . . . . . . . . . . . . . 16 81 3.2.6. Operation . . . . . . . . . . . . . . . 17 82 3.2.7. Operation . . . . . . . . . . . . . . 18 83 3.2.8. Operation . . . . . . . . . . . . . . . . . 18 84 3.2.9. Operation . . . . . . . . . . . . . 18 85 3.2.10. Operation . . . . . . . . . . . . . . 19 86 3.3. Model Components . . . . . . . . . . . . . . . . . . . . 19 87 3.3.1. Users . . . . . . . . . . . . . . . . . . . . . . . . 19 88 3.3.2. Groups . . . . . . . . . . . . . . . . . . . . . . . 19 89 3.3.3. Emergency Recovery Session . . . . . . . . . . . . . 19 90 3.3.4. Global Enforcement Controls . . . . . . . . . . . . . 20 91 3.3.4.1. enable-nacm Switch . . . . . . . . . . . . . . . 20 92 3.3.4.2. read-default Switch . . . . . . . . . . . . . . . 20 93 3.3.4.3. write-default Switch . . . . . . . . . . . . . . 20 94 3.3.4.4. exec-default Switch . . . . . . . . . . . . . . . 21 95 3.3.4.5. enable-external-groups Switch . . . . . . . . . . 21 96 3.3.5. Access Control Rules . . . . . . . . . . . . . . . . 21 98 3.4. Access Control Enforcement Procedures . . . . . . . . . . 21 99 3.4.1. Initial Operation . . . . . . . . . . . . . . . . . . 22 100 3.4.2. Session Establishment . . . . . . . . . . . . . . . . 22 101 3.4.3. "access-denied" Error Handling . . . . . . . . . . . 22 102 3.4.4. Incoming RPC Message Validation . . . . . . . . . . . 22 103 3.4.5. Data Node Access Validation . . . . . . . . . . . . . 25 104 3.4.6. Outgoing Authorization . . . . . . . . 27 105 3.5. Data Model Definitions . . . . . . . . . . . . . . . . . 29 106 3.5.1. Data Organization . . . . . . . . . . . . . . . . . . 30 107 3.5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 30 108 3.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 109 3.7. Security Considerations . . . . . . . . . . . . . . . . . 41 110 3.7.1. NACM Configuration and Monitoring Considerations . . 41 111 3.7.2. General Configuration Issues . . . . . . . . . . . . 42 112 3.7.3. Data Model Design Considerations . . . . . . . . . . 44 113 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 114 4.1. Normative References . . . . . . . . . . . . . . . . . . 44 115 4.2. Informative References . . . . . . . . . . . . . . . . . 45 116 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 46 117 A.1. v04 to v05 . . . . . . . . . . . . . . . . . . . . . . . 46 118 A.2. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 46 119 A.3. v02 to v03 . . . . . . . . . . . . . . . . . . . . . . . 46 120 A.4. v01 to v02 . . . . . . . . . . . . . . . . . . . . . . . 46 121 A.5. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 46 122 A.6. v00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 123 Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 47 124 B.1. Example . . . . . . . . . . . . . . . . . . . . 47 125 B.2. Module Rule Example . . . . . . . . . . . . . . . . . . . 48 126 B.3. Protocol Operation Rule Example . . . . . . . . . . . . . 49 127 B.4. Data Node Rule Example . . . . . . . . . . . . . . . . . 51 128 B.5. Notification Rule Example . . . . . . . . . . . . . . . . 53 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 131 1. Introduction 133 The NETCONF and RESTCONF protocols do not provide any standard 134 mechanisms to restrict the protocol operations and content that each 135 user is authorized to access. 137 There is a need for interoperable management of the controlled access 138 to administrator-selected portions of the available NETCONF or 139 RESTCONF content within a particular server. 141 This document addresses access control mechanisms for the Operations 142 and Content layers of NETCONF, as defined in [RFC6241], and RESTCONF, 143 as defined in [RFC8040]. It contains three main sections: 145 1. Access Control Design Objectives 146 2. NETCONF Access Control Model (NACM) 148 3. YANG Data Model (ietf-netconf-acm.yang) 150 YANG version 1.1 [RFC7950] adds two new constructs that need special 151 access control handling. The "action" statement is similar to the 152 "rpc" statement, except it is located within a data node. The 153 "notification" statement can also be located within a data node. 155 1.1. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 The following terms are defined in 162 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 164 o datastore 166 o configuration datastore 168 o conventional configuration datastore 170 o candidate configuration datastore 172 o running configuration datastore 174 o startup configuration datastore 176 o operational state datastore 178 o client 180 o server 182 The following terms are defined in [RFC6241] and are not redefined 183 here: 185 o protocol operation 187 o session 189 o user 191 The following terms are defined in [RFC7950] and are not redefined 192 here: 194 o action 196 o data node 198 o data definition statement 200 The following terms are defined in [RFC8040] and are not redefined 201 here: 203 o data resource 205 o datastore resource 207 o operation resource 209 o target resource 211 The following term is defined in [RFC7230] and is not redefined here: 213 o request URI 215 The following terms are used throughout this document: 217 access control: A security feature provided by the server that 218 allows an administrator to restrict access to a subset of all 219 protocol operations and data, based on various criteria. 221 access control model (ACM): A conceptual model used to configure and 222 monitor the access control procedures desired by the administrator 223 to enforce a particular access control policy. 225 access control rule: The criterion used to determine if a particular 226 access operation will be permitted or denied. 228 access operation: How a request attempts to access a conceptual 229 object. One of "none", "read", "create", "delete", "update", or 230 "execute". 232 data node hierarchy: The hierarchy of data nodes that identifies the 233 specific "action" or "notification" node in the datastore. 235 recovery session: A special administrative session that is given 236 unlimited NETCONF access and is exempt from all access control 237 enforcement. The mechanism(s) used by a server to control and 238 identify whether or not a session is a recovery session are 239 implementation specific and outside the scope of this document. 241 write access: A shorthand for the "create", "delete", and "update" 242 access operations. 244 1.2. Changes Since RFC 6536 246 The NACM procedures and data model have been updated to support new 247 data modeling capabilities in the version 1.1. of the YANG data 248 modeling language. The "action" and "notification" statements can be 249 used within data nodes to define data-model specific operations and 250 notifications. 252 An important use-case for these new YANG statements is the increased 253 access control granularity that can be achieved over top-level "rpc" 254 and "notification" statements. The new "action" and "notification" 255 statements are used within data nodes, and access to the action or 256 notification can be restricted to specific instances of these data 257 nodes. 259 Support for the RESTCONF protocol has been added. The RESTCONF 260 operations are similar to the NETCONF operations, so a simple mapping 261 to the existing NACM procedures and data model is possible. 263 2. Access Control Design Objectives 265 This section documents the design objectives for the NETCONF Access 266 Control Model presented in Section 3. 268 2.1. Access Control Points 270 NETCONF allows server implementors to add new custom protocol 271 operations, and the YANG Data Modeling Language supports this 272 feature. These operations can be defined in standard or proprietary 273 YANG modules. 275 It is not possible to design an ACM for NETCONF that only focuses on 276 a static set of standard protocol operations defined by the NETCONF 277 protocol itself, like some other protocols. Since few assumptions 278 can be made about an arbitrary protocol operation, the NETCONF 279 architectural server components need to be protected at three 280 conceptual control points. 282 These access control points, described in Figure 1, are as follows: 284 protocol operation: Permission to invoke specific protocol 285 operations. 287 datastore: Permission to read and/or alter specific data nodes 288 within any datastore. 290 notification: Permission to receive specific notification event 291 types. 293 +-------------+ +-------------+ 294 client | protocol | | data node | 295 request --> | operation | -------------> | access | 296 | allowed? | datastore | allowed? | 297 +-------------+ or state +-------------+ 298 data access 300 +----------------+ 301 | notification | 302 event --> | allowed? | 303 +----------------+ 305 Figure 1 307 2.2. Simplicity 309 There is concern that a complicated ACM will not be widely deployed 310 because it is too hard to use. It needs to be easy to do simple 311 things and possible to do complex things, instead of hard to do 312 everything. 314 Configuration of the access control system needs to be as simple as 315 possible. Simple and common tasks need to be easy to configure and 316 require little expertise or domain-specific knowledge. Complex tasks 317 are possible using additional mechanisms, which may require 318 additional expertise. 320 A single set of access control rules ought to be able to control all 321 types of NETCONF protocol operation invocation, all datastore access, 322 and all notification events. 324 Access control ought to be defined with a small and familiar set of 325 permissions, while still allowing full control of datastore access. 327 2.3. Procedural Interface 329 The NETCONF protocol uses a remote procedure call model and an 330 extensible set of protocol operations. Access control for any 331 possible protocol operation is necessary. 333 2.4. Datastore Access 335 It is necessary to control access to specific nodes and subtrees 336 within the datastore, regardless of which protocol operation, 337 standard or proprietary, was used to access the datastore. 339 2.5. Users and Groups 341 It is necessary that access control rules for a single user or a 342 configurable group of users can be configured. 344 The ACM needs to support the concept of administrative groups, to 345 support the well-established distinction between a root account and 346 other types of less-privileged conceptual user accounts. These 347 groups need to be configurable by the administrator. 349 It is necessary that the user-to-group mapping can be delegated to a 350 central server, such as a RADIUS server [RFC2865][RFC5607]. Since 351 authentication is performed by the transport layer and RADIUS 352 performs authentication and service authorization at the same time, 353 the underlying transport protocol needs to be able to report a set of 354 group names associated with the user to the server. It is necessary 355 that the administrator can disable the usage of these group names 356 within the ACM. 358 2.6. Maintenance 360 It ought to be possible to disable part or all of the access control 361 model enforcement procedures without deleting any access control 362 rules. 364 2.7. Configuration Capabilities 366 Suitable configuration and monitoring mechanisms are needed to allow 367 an administrator to easily manage all aspects of the ACM's behavior. 368 A standard data model, suitable for use with the 369 protocol operation, needs to be available for this purpose. 371 Access control rules to restrict access operations on specific 372 subtrees within the configuration datastore need to be supported. 374 2.8. Identifying Security-Sensitive Content 376 One of the most important aspects of the data model documentation, 377 and biggest concerns during deployment, is the identification of 378 security-sensitive content. This applies to protocol operations in 379 NETCONF, not just data and notifications. 381 It is mandatory for security-sensitive objects to be documented in 382 the Security Considerations section of an RFC. This is nice, but it 383 is not good enough, for the following reasons: 385 o This documentation-only approach forces administrators to study 386 the RFC and determine if there are any potential security risks 387 introduced by a new data model. 389 o If any security risks are identified, then the administrator must 390 study some more RFC text and determine how to mitigate the 391 security risk(s). 393 o The ACM on each server must be configured to mitigate the security 394 risks, e.g., require privileged access to read or write the 395 specific data identified in the Security Considerations section. 397 o If the ACM is not pre-configured, then there will be a time window 398 of vulnerability after the new data model is loaded and before the 399 new access control rules for that data model are configured, 400 enabled, and debugged. 402 Often, the administrator just wants to disable default access to the 403 secure content, so no inadvertent or malicious changes can be made to 404 the server. This allows the default rules to be more lenient, 405 without significantly increasing the security risk. 407 A data model designer needs to be able to use machine-readable 408 statements to identify content that needs to be protected by default. 409 This will allow client and server tools to automatically identify 410 data-model-specific security risks, by denying access to sensitive 411 data unless the user is explicitly authorized to perform the 412 requested access operation. 414 3. NETCONF Access Control Model (NACM) 416 3.1. Introduction 418 This section provides a high-level overview of the access control 419 model structure. It describes the NETCONF protocol message 420 processing model and the conceptual access control requirements 421 within that model. 423 3.1.1. Features 425 The NACM data model provides the following features: 427 o Independent control of remote procedure call (RPC), action, data, 428 and notification access. 430 o Simple access control rules configuration data model that is easy 431 to use. 433 o The concept of an emergency recovery session is supported, but 434 configuration of the server for this purpose is beyond the scope 435 of this document. An emergency recovery session will bypass all 436 access control enforcement, in order to allow it to initialize or 437 repair the NACM configuration. 439 o A simple and familiar set of datastore permissions is used. 441 o Support for YANG security tagging (e.g., "nacm:default-deny-write" 442 statement) allows default security modes to automatically exclude 443 sensitive data. 445 o Separate default access modes for read, write, and execute 446 permissions. 448 o Access control rules are applied to configurable groups of users. 450 o The access control enforcement procedures can be disabled during 451 operation, without deleting any access control rules, in order to 452 debug operational problems. 454 o Access control rules are simple to configure. 456 o The number of denied protocol operation requests and denied 457 datastore write requests can be monitored by the client. 459 o Simple unconstrained YANG instance identifiers are used to 460 configure access control rules for specific data nodes. 462 3.1.2. External Dependencies 464 The NETCONF protocol [RFC6241] is used for network management 465 purposes within this document. 467 The RESTCONF protocol [RFC8040] is used for network management 468 purposes within this document. 470 The YANG Data Modeling Language [RFC7950] is used to define the data 471 models for use with the NETCONF or RESTCONF protocols. YANG is also 472 used to define the data model in this document. 474 3.1.3. Message Processing Model 476 The following diagram shows the conceptual message flow model, 477 including the points at which access control is applied during 478 NETCONF message processing. 480 RESTCONF operations are mapped to the access control model based on 481 the HTTP method and resource class used in the operation. For 482 example, a POST method on a data resource is considered "write data 483 node" access, but a POST method on an operation resource is 484 considered "operation" access. 486 +-------------------------+ 487 | session | 488 | (username) | 489 +-------------------------+ 490 | ^ 491 V | 492 +--------------+ +---------------+ 493 | message | | message | 494 | dispatcher | | generator | 495 +--------------+ +---------------+ 496 | | ^ ^ 497 | V | | 498 | +=============+ | | 499 | | pre-read | | | 500 | | data node | | | 501 | | acc. ctl | | | 502 | +=============+ | | 503 | | | | 504 V V | | 505 +===========+ +-------------+ +----------------+ 506 | operation |---> | reply | | | 507 | acc. ctl | | generator | | generator | 508 +===========+ +-------------+ +----------------+ 509 | ^ ^ ^ 510 V +------+ | | 511 +-----------+ | +=============+ +================+ 512 | operation | | | read | | | 513 | processor |-+ | data node | | access ctl | 514 | | | acc. ctl | | | 515 +-----------+ +=============+ +================+ 516 | | ^ ^ ^ 517 V +----------------+ | | | 518 +===========+ | | | +============+ 519 | write | | | | | pre-read | 520 | data node | | | | | data node | 521 | acc. ctl | -----------+ | | | | acc. ctl | 522 +===========+ | | | | +============+ 523 | | | | | ^ 524 V V V | | | 525 +---------------+ +-------------------+ 526 | configuration | ---> | server | 527 | datastore | | instrumentation | 528 | | <--- | | 529 +---------------+ +-------------------+ 531 Figure 2 533 The following high-level sequence of conceptual processing steps is 534 executed for each received message, if access control 535 enforcement is enabled: 537 o For each active session, access control is applied individually to 538 all messages (except ) received by the 539 server, unless the session is identified as a recovery session. 541 o If the operation defined in [RFC7950] is invoked, then 542 read access is required for all instances in the hierarchy of data 543 nodes that identifies the specific action in the datastore, and 544 execute access is required for the action node. If the user is 545 not authorized to read all the specified data nodes and execute 546 the action, then the request is rejected with an "access-denied" 547 error. 549 o Otherwise, if the user is not authorized to execute the specified 550 protocol operation, then the request is rejected with an "access- 551 denied" error. 553 o If a datastore is accessed by the protocol operation, then the 554 server checks if the client is authorized to access the nodes in 555 the datastore. If the user is not authorized to perform the 556 requested access operation on the requested data, then the request 557 is rejected with an "access-denied" error. 559 The following sequence of conceptual processing steps is executed for 560 each generated notification event, if access control enforcement is 561 enabled: 563 o Server instrumentation generates a notification for a particular 564 subscription. 566 o If the notification statement is specified within a data subtree, 567 as specified in [RFC7950], then read access is required for all 568 instances in the hierarchy of data nodes that identifies the 569 specific notification in the datastore, and read access is 570 required for the notification node. If the user is not authorized 571 to read all the specified data nodes and the notification node, 572 then the notification is dropped for that subscription. 574 o If the notification statement is a top-level statement, the 575 notification access control enforcer checks the notification event 576 type, and if it is one that the user is not authorized to read, 577 then the notification is dropped for that subscription. 579 3.2. Datastore Access 581 The same access control rules apply to all datastores that support 582 NACM, for example, the candidate configuration datastore or the 583 running configuration datastore. 585 All conventional configuration datastores and the operational state 586 datastore are controlled by NACM. Local or remote files or 587 datastores accessed via the parameter are not controlled by 588 NACM. 590 3.2.1. Mapping New Datastores to NACM 592 It is possible that new datastores will be defined over time for use 593 with the NETCONF protocol. NACM MAY be applied to other datastores 594 that have similar access rights as defined in NACM. To apply NACM to 595 a new datastore, the new datastore specification needs to define how 596 it maps to the NACM CRUDX access rights. It is possible only a 597 subset of the NACM access rights would be applicable. For example, 598 only retrieval access control would be needed for a read-only 599 datastore. Operations and access rights not supported by the NACM 600 CRUDX model are outside the scope of this document. A datastore does 601 not need to use NACM, e.g., the datastore specification defines 602 something else, or does not use access control. 604 3.2.2. Access Rights 606 A small set of hard-wired datastore access rights is needed to 607 control access to all possible NETCONF protocol operations, including 608 vendor extensions to the standard protocol operation set. 610 The "CRUDX" model can support all NETCONF protocol operations: 612 o Create: allows the client to add a new data node instance to a 613 datastore. 615 o Read: allows the client to read a data node instance from a 616 datastore or receive the notification event type. 618 o Update: allows the client to update an existing data node instance 619 in a datastore. 621 o Delete: allows the client to delete a data node instance from a 622 datastore. 624 o eXec: allows the client to execute the operation. 626 3.2.3. RESTCONF Methods 628 The RESTCONF protocol utilizes HTTP methods to perform datastore 629 operations, similar to the NETCONF protocol. The NACM procedures 630 were originally written for NETCONF protocol operations so the 631 RESTCONF methods are mapped to NETCONF operations for the purpose of 632 access control processing. The enforcement procedures described 633 within this document apply to both protocols unless explicitly stated 634 otherwise. 636 The request URI needs to be considered when processing RESTCONF 637 requests on data resources: 639 o For HEAD and GET requests, any data nodes which are ancestor nodes 640 of the target resource are considered to be part of the retrieval 641 request for access control purposes. 643 o For PUT, PATCH, and DELETE requests, any data nodes which are 644 ancestor nodes of the target resource are not considered to be 645 part of the edit request for access control purposes. The access 646 operation for these nodes is considered to be "none". The edit 647 begins at the target resource. 649 o For POST requests on data resources, any data nodes which are 650 specified in the request URI, including the target resource, are 651 not considered to be part of the edit request for access control 652 purposes. The access operation for these nodes is considered to 653 be "none". The edit begins at a child node of the target 654 resource, specified in the message body. 656 Not all RESTCONF methods are subject to access control. The 657 following table specifies how each method is mapped to NETCONF 658 protocol operations. The value "none" indicates that NACM is not 659 applied at all to the specific RESTCONF method. 661 +---------+-----------------+---------------------+-----------------+ 662 | method | resource class | NETCONF operation | Access | 663 | | | | operation | 664 +---------+-----------------+---------------------+-----------------+ 665 | OPTIONS | all | none | N/A | 666 | HEAD | all | | N/A | 667 | GET | all | | N/A | 668 | POST | datastore, data | | create | 669 | POST | operation | specified operation | N/A | 670 | PUT | data | | create, replace | 671 | PUT | datastore | | replace | 672 | PATCH | data, datastore | | merge | 673 | DELETE | data | | delete | 674 +---------+-----------------+---------------------+-----------------+ 676 Table 1: Mapping RESTCONF Methods to NETCONF 678 3.2.4. and Operations 680 The NACM access rights are not directly coupled to the and 681 protocol operations, but apply to all operations 682 that would result in a "read" access operation to the target 683 datastore. This section describes how these access rights apply to 684 the specific access operations supported by the and protocol operations. 687 Data nodes to which the client does not have read access are silently 688 omitted from the message. This is done to allow NETCONF 689 filters for and to function properly, instead of 690 causing an "access-denied" error because the filter criteria would 691 otherwise include unauthorized read access to some data nodes. For 692 NETCONF filtering purposes, the selection criteria is applied to the 693 subset of nodes that the user is authorized to read, not the entire 694 datastore. 696 3.2.5. Operation 698 The NACM access rights are not directly coupled to the 699 "operation" attribute, although they are similar. Instead, a NACM 700 access right applies to all protocol operations that would result in 701 a particular access operation to the target datastore. This section 702 describes how these access rights apply to the specific access 703 operations supported by the protocol operation. 705 If the effective access operation is "none" (i.e., default- 706 operation="none") for a particular data node, then no access control 707 is applied to that data node. This is required to allow access to a 708 subtree within a larger data structure. For example, a user may be 709 authorized to create a new "/interfaces/interface" list entry but not 710 be authorized to create or delete its parent container 711 ("/interfaces"). If the "/interfaces" container already exists in 712 the target datastore, then the effective operation will be "none" for 713 the "/interfaces" node if an "/interfaces/interface" list entry is 714 edited. 716 If the protocol operation would result in the creation of a datastore 717 node and the user does not have "create" access permission for that 718 node, the protocol operation is rejected with an "access-denied" 719 error. 721 If the protocol operation would result in the deletion of a datastore 722 node and the user does not have "delete" access permission for that 723 node, the protocol operation is rejected with an "access-denied" 724 error. 726 If the protocol operation would result in the modification of a 727 datastore node and the user does not have "update" access permission 728 for that node, the protocol operation is rejected with an "access- 729 denied" error. 731 A "merge" or "replace" operation may include data nodes 732 that do not alter portions of the existing datastore. For example, a 733 container or list node may be present for naming purposes but does 734 not actually alter the corresponding datastore node. These unaltered 735 data nodes are ignored by the server and do not require any access 736 rights by the client. 738 A "merge" operation may include data nodes but not 739 include particular child data nodes that are present in the 740 datastore. These missing data nodes within the scope of a "merge" 741 operation are ignored by the server and do not require 742 any access rights by the client. 744 The contents of specific restricted datastore nodes MUST NOT be 745 exposed in any elements within the reply. 747 3.2.6. Operation 749 Access control for the protocol operation requires 750 special consideration because the administrator may be replacing the 751 entire target datastore. 753 If the source of the protocol operation is the running 754 configuration datastore and the target is the startup configuration 755 datastore, the client is only required to have permission to execute 756 the protocol operation. 758 Otherwise: 760 o If the source of the operation is a datastore, then 761 data nodes to which the client does not have read access are 762 silently omitted. 764 o If the target of the operation is a datastore, the 765 client needs access to the modified nodes, specifically: 767 * If the protocol operation would result in the creation of a 768 datastore node and the user does not have "create" access 769 permission for that node, the protocol operation is rejected 770 with an "access-denied" error. 772 * If the protocol operation would result in the deletion of a 773 datastore node and the user does not have "delete" access 774 permission for that node, the protocol operation is rejected 775 with an "access-denied" error. 777 * If the protocol operation would result in the modification of a 778 datastore node and the user does not have "update" access 779 permission for that node, the protocol operation is rejected 780 with an "access-denied" error. 782 3.2.7. Operation 784 Access to the protocol operation is denied by 785 default. The "exec-default" leaf does not apply to this protocol 786 operation. Access control rules must be explicitly configured to 787 allow invocation by a non-recovery session. 789 3.2.8. Operation 791 The server MUST determine the exact nodes in the running 792 configuration datastore that are actually different and only check 793 "create", "update", and "delete" access permissions for this set of 794 nodes, which could be empty. 796 For example, if a session can read the entire datastore but only 797 change one leaf, that session needs to be able to edit and commit 798 that one leaf. 800 3.2.9. Operation 802 The client is only required to have permission to execute the 803 protocol operation. No datastore permissions are 804 needed. 806 3.2.10. Operation 808 The operation does not directly alter a datastore. 809 However, it allows one session to disrupt another session that is 810 editing a datastore. 812 Access to the protocol operation is denied by default. 813 The "exec-default" leaf does not apply to this protocol operation. 814 Access control rules must be explicitly configured to allow 815 invocation by a non-recovery session. 817 3.3. Model Components 819 This section defines the conceptual components related to the access 820 control model. 822 3.3.1. Users 824 A "user" is the conceptual entity that is associated with the access 825 permissions granted to a particular session. A user is identified by 826 a string that is unique within the server. 828 As described in [RFC6241], the username string is derived from the 829 transport layer during session establishment. If the transport layer 830 cannot authenticate the user, the session is terminated. 832 3.3.2. Groups 834 Access to a specific NETCONF protocol operation is granted to a 835 session, associated with a group, not a user. 837 A group is identified by its name. All group names are unique within 838 the server. 840 A group member is identified by a username string. 842 The same user can be a member of multiple groups. 844 3.3.3. Emergency Recovery Session 846 The server MAY support a recovery session mechanism, which will 847 bypass all access control enforcement. This is useful for 848 restricting initial access and repairing a broken access control 849 configuration. 851 3.3.4. Global Enforcement Controls 853 There are five global controls that are used to help control how 854 access control is enforced. 856 3.3.4.1. enable-nacm Switch 858 A global "enable-nacm" on/off switch is provided to enable or disable 859 all access control enforcement. When this global switch is set to 860 "true", then all requests are checked against the access control 861 rules and only permitted if configured to allow the specific access 862 request. When this global switch is set to "false", then all access 863 requested are permitted. 865 3.3.4.2. read-default Switch 867 An on/off "read-default" switch is provided to enable or disable 868 default access to receive data in replies and notifications. When 869 the "enable-nacm" global switch is set to "true", then this global 870 switch is relevant if no matching access control rule is found to 871 explicitly permit or deny read access to the requested datastore data 872 or notification event type. 874 When this global switch is set to "permit" and no matching access 875 control rule is found for the datastore read or notification event 876 requested, then access is permitted. 878 When this global switch is set to "deny" and no matching access 879 control rule is found for the datastore read or notification event 880 requested, then access is denied. 882 3.3.4.3. write-default Switch 884 An on/off "write-default" switch is provided to enable or disable 885 default access to alter configuration data. When the "enable-nacm" 886 global switch is set to "true", then this global switch is relevant 887 if no matching access control rule is found to explicitly permit or 888 deny write access to the requested datastore data. 890 When this global switch is set to "permit" and no matching access 891 control rule is found for the datastore write requested, then access 892 is permitted. 894 When this global switch is set to "deny" and no matching access 895 control rule is found for the datastore write requested, then access 896 is denied. 898 3.3.4.4. exec-default Switch 900 An on/off "exec-default" switch is provided to enable or disable 901 default access to execute protocol operations. When the "enable- 902 nacm" global switch is set to "true", then this global switch is 903 relevant if no matching access control rule is found to explicitly 904 permit or deny access to the requested NETCONF protocol operation. 906 When this global switch is set to "permit" and no matching access 907 control rule is found for the NETCONF protocol operation requested, 908 then access is permitted. 910 When this global switch is set to "deny" and no matching access 911 control rule is found for the NETCONF protocol operation requested, 912 then access is denied. 914 3.3.4.5. enable-external-groups Switch 916 When this global switch is set to "true", the group names reported by 917 the transport layer for a session are used together with the locally 918 configured group names to determine the access control rules for the 919 session. 921 When this switch is set to "false", the group names reported by the 922 transport layer are ignored by NACM. 924 3.3.5. Access Control Rules 926 There are four types of rules available in NACM: 928 module rule: controls access for definitions in a specific YANG 929 module, identified by its name. 931 protocol operation rule: controls access for a specific protocol 932 operation, identified by its YANG module and name. 934 data node rule: controls access for a specific data node, identified 935 by its path location within the conceptual XML document for the 936 data node. 938 notification rule: controls access for a specific notification event 939 type, identified by its YANG module and name. 941 3.4. Access Control Enforcement Procedures 943 There are seven separate phases that need to be addressed, four of 944 which are related to the NETCONF message processing model 945 (Section 3.1.3). In addition, the initial startup mode for a NETCONF 946 server, session establishment, and "access-denied" error-handling 947 procedures also need to be considered. 949 The server MUST use the access control rules in effect at the time it 950 starts processing the message. The same access control rules MUST 951 stay in effect for the processing of the entire message. 953 3.4.1. Initial Operation 955 Upon the very first startup of the NETCONF server, the access control 956 configuration will probably not be present. If it isn't, a server 957 MUST NOT allow any write access to any session role except a recovery 958 session. 960 Access rules are enforced any time a request is initiated from a user 961 session. Access control is not enforced for server-initiated access 962 requests, such as the initial load of the running configuration 963 datastore, during bootup. 965 3.4.2. Session Establishment 967 The access control model applies specifically to the well-formed XML 968 content transferred between a client and a server after session 969 establishment has been completed and after the exchange has 970 been successfully completed. 972 Once session establishment is completed and a user has been 973 authenticated, the transport layer reports the username and a 974 possibly empty set of group names associated with the user to the 975 NETCONF server. The NETCONF server will enforce the access control 976 rules, based on the supplied username, group names, and the 977 configuration data stored on the server. 979 3.4.3. "access-denied" Error Handling 981 The "access-denied" error-tag is generated when the access control 982 system denies access to either a request to invoke a protocol 983 operation or a request to perform a particular access operation on 984 the configuration datastore. 986 A server MUST NOT include any information the client is not allowed 987 to read in any elements within the response. 989 3.4.4. Incoming RPC Message Validation 991 The diagram below shows the basic conceptual structure of the access 992 control processing model for incoming NETCONF messages within a 993 server. 995 NETCONF server 996 +------------+ 997 | XML | 998 | message | 999 | dispatcher | 1000 +------------+ 1001 | 1002 | 1003 V 1004 +------------+ 1005 | NC-base NS | 1006 | | 1007 +------------+ 1008 | | | 1009 | | +-------------------------+ 1010 | +------------+ | 1011 V V V 1012 +-----------+ +---------------+ +------------+ 1013 | Vendor NS | | NC-base NS | | NC-base NS | 1014 | | | | | | 1015 +-----------+ +---------------+ +------------+ 1016 | | 1017 | | 1018 V V 1019 +----------------------+ 1020 | | 1021 | configuration | 1022 | datastore | 1023 +----------------------+ 1025 Figure 3 1027 Access control begins with the message dispatcher. 1029 After the server validates the element and determines the 1030 namespace URI and the element name of the protocol operation being 1031 requested, the server verifies that the user is authorized to invoke 1032 the protocol operation. 1034 The server MUST separately authorize every protocol operation by 1035 following these steps: 1037 1. If the "enable-nacm" leaf is set to "false", then the protocol 1038 operation is permitted. 1040 2. If the requesting session is identified as a recovery session, 1041 then the protocol operation is permitted. 1043 3. If the requested operation is the NETCONF 1044 protocol operation, then the protocol operation is permitted. 1046 4. Check all the "group" entries for ones that contain a "user- 1047 name" entry that equals the username for the session making the 1048 request. If the "enable-external-groups" leaf is "true", add to 1049 these groups the set of groups provided by the transport layer. 1051 5. If no groups are found, continue with step 10. 1053 6. Process all rule-list entries, in the order they appear in the 1054 configuration. If a rule-list's "group" leaf-list does not 1055 match any of the user's groups, proceed to the next rule-list 1056 entry. 1058 7. For each rule-list entry found, process all rules, in order, 1059 until a rule that matches the requested access operation is 1060 found. A rule matches if all of the following criteria are met: 1062 * The rule's "module-name" leaf is "*" or equals the name of 1063 the YANG module where the protocol operation is defined. 1065 * The rule does not have a "rule-type" defined or the "rule- 1066 type" is "protocol-operation" and the "rpc-name" is "*" or 1067 equals the name of the requested protocol operation. 1069 * The rule's "access-operations" leaf has the "exec" bit set or 1070 has the special value "*". 1072 8. If a matching rule is found, then the "action" leaf is checked. 1073 If it is equal to "permit", then the protocol operation is 1074 permitted; otherwise, it is denied. 1076 9. At this point, no matching rule was found in any rule-list 1077 entry. 1079 10. If the requested protocol operation is defined in a YANG module 1080 advertised in the server capabilities and the "rpc" statement 1081 contains a "nacm:default-deny-all" statement, then the protocol 1082 operation is denied. 1084 11. If the requested protocol operation is the NETCONF or , then the protocol operation is 1086 denied. 1088 12. If the "exec-default" leaf is set to "permit", then permit the 1089 protocol operation; otherwise, deny the request. 1091 If the user is not authorized to invoke the protocol operation, then 1092 an is generated with the following information: 1094 error-tag: access-denied 1096 error-path: Identifies the requested protocol operation. The 1097 following example represents the protocol operation 1098 in the NETCONF base namespace: 1100 1102 /nc:rpc/nc:edit-config 1103 1105 If a datastore is accessed, either directly or as a side effect of 1106 the protocol operation, then the server MUST intercept the access 1107 operation and make sure the user is authorized to perform the 1108 requested access operation on the specified data, as defined in 1109 Section 3.4.5. 1111 3.4.5. Data Node Access Validation 1113 If a data node within a datastore is accessed, or an action or 1114 notification tied to a data node, then the server MUST ensure that 1115 the user is authorized to perform the requested "read", "create", 1116 "update", "delete", or "execute" access operation on the specified 1117 data node. 1119 If an action is requested to be executed, the server MUST ensure that 1120 the user is authorized to perform the "execute" access operation on 1121 the requested action. 1123 If a notification tied to a data node is generated, the server MUST 1124 ensure that the user is authorized to perform the "read" access 1125 operation on the requested notification. 1127 The data node access request is authorized by following these steps: 1129 1. If the "enable-nacm" leaf is set to "false", then the access 1130 operation is permitted. 1132 2. If the requesting session is identified as a recovery session, 1133 then the access operation is permitted. 1135 3. Check all the "group" entries for ones that contain a "user- 1136 name" entry that equals the username for the session making the 1137 request. If the "enable-external-groups" leaf is "true", add to 1138 these groups the set of groups provided by the transport layer. 1140 4. If no groups are found, continue with step 9. 1142 5. Process all rule-list entries, in the order they appear in the 1143 configuration. If a rule-list's "group" leaf-list does not 1144 match any of the user's groups, proceed to the next rule-list 1145 entry. 1147 6. For each rule-list entry found, process all rules, in order, 1148 until a rule that matches the requested access operation is 1149 found. A rule matches if all of the following criteria are met: 1151 * The rule's "module-name" leaf is "*" or equals the name of 1152 the YANG module where the requested data node is defined. 1154 * The rule does not have a "rule-type" defined or the "rule- 1155 type" is "data-node" and the "path" matches the requested 1156 data node, action node, or notification node. 1158 * For a "read" access operation, the rule's "access-operations" 1159 leaf has the "read" bit set or has the special value "*". 1161 * For a "create" access operation, the rule's "access- 1162 operations" leaf has the "create" bit set or has the special 1163 value "*". 1165 * For a "delete" access operation, the rule's "access- 1166 operations" leaf has the "delete" bit set or has the special 1167 value "*". 1169 * For an "update" access operation, the rule's "access- 1170 operations" leaf has the "update" bit set or has the special 1171 value "*". 1173 * For an "execute" access operation, the rule's "access- 1174 operations" leaf has the "exec" bit set or has the special 1175 value "*". 1177 7. If a matching rule is found, then the "action" leaf is checked. 1178 If it is equal to "permit", then the data node access is 1179 permitted; otherwise, it is denied. For a "read" access 1180 operation, "denied" means that the requested data is not 1181 returned in the reply. 1183 8. At this point, no matching rule was found in any rule-list 1184 entry. 1186 9. For a "read" access operation, if the requested data node is 1187 defined in a YANG module advertised in the server capabilities 1188 and the data definition statement contains a "nacm:default-deny- 1189 all" statement, then the requested data node is not included in 1190 the reply. 1192 10. For a "write" access operation, if the requested data node is 1193 defined in a YANG module advertised in the server capabilities 1194 and the data definition statement contains a "nacm:default-deny- 1195 write" or a "nacm:default-deny-all" statement, then the data 1196 node access request is denied. 1198 11. For a "read" access operation, if the "read-default" leaf is set 1199 to "permit", then include the requested data node in the reply; 1200 otherwise, do not include the requested data node in the reply. 1202 12. For a "write" access operation, if the "write-default" leaf is 1203 set to "permit", then permit the data node access request; 1204 otherwise, deny the request. 1206 13. For an "execute" access operation, if the "exec-default" leaf is 1207 set to "permit", then permit the request; otherwise, deny the 1208 request. 1210 3.4.6. Outgoing Authorization 1212 Configuration of access control rules specifically for descendant 1213 nodes of the notification event type element are outside the scope of 1214 this document. If the user is authorized to receive the notification 1215 event type, then it is also authorized to receive any data it 1216 contains. 1218 If the notification is specified within a data subtree, as specified 1219 in [RFC7950], then read access to the notification is required. 1220 Processing continues as described in Section 3.4.5. 1222 The following figure shows the conceptual message processing model 1223 for outgoing messages. 1225 NETCONF server 1226 +------------+ 1227 | XML | 1228 | message | 1229 | generator | 1230 +------------+ 1231 ^ 1232 | 1233 +----------------+ 1234 | | 1235 | generator | 1236 +----------------+ 1237 ^ 1238 | 1239 +=================+ 1240 | | 1241 | access control | 1242 | | 1243 +=================+ 1244 ^ 1245 | 1246 +------------------------+ 1247 | server instrumentation | 1248 +------------------------+ 1249 | ^ 1250 V | 1251 +----------------------+ 1252 | configuration | 1253 | datastore | 1254 +----------------------+ 1256 Figure 4 1258 The generation of a notification for a specific subscription 1259 [RFC5277] is authorized by following these steps: 1261 1. If the "enable-nacm" leaf is set to "false", then the 1262 notification is permitted. 1264 2. If the session is identified as a recovery session, then the 1265 notification is permitted. 1267 3. If the notification is the NETCONF or 1268 event type [RFC5277], then the 1269 notification is permitted. 1271 4. Check all the "group" entries for ones that contain a "user- 1272 name" entry that equals the username for the session making the 1273 request. If the "enable-external-groups" leaf is "true", add to 1274 these groups the set of groups provided by the transport layer. 1276 5. If no groups are found, continue with step 10. 1278 6. Process all rule-list entries, in the order they appear in the 1279 configuration. If a rule-list's "group" leaf-list does not 1280 match any of the user's groups, proceed to the next rule-list 1281 entry. 1283 7. For each rule-list entry found, process all rules, in order, 1284 until a rule that matches the requested access operation is 1285 found. A rule matches if all of the following criteria are met: 1287 * The rule's "module-name" leaf is "*" or equals the name of 1288 the YANG module where the notification is defined. 1290 * The rule does not have a "rule-type" defined or the "rule- 1291 type" is "notification" and the "notification-name" is "*" or 1292 equals the name of the notification. 1294 * The rule's "access-operations" leaf has the "read" bit set or 1295 has the special value "*". 1297 8. If a matching rule is found, then the "action" leaf is checked. 1298 If it is equal to "permit", then permit the notification; 1299 otherwise, drop the notification for the associated 1300 subscription. 1302 9. Otherwise, no matching rule was found in any rule-list entry. 1304 10. If the requested notification is defined in a YANG module 1305 advertised in the server capabilities and the "notification" 1306 statement contains a "nacm:default-deny-all" statement, then the 1307 notification is dropped for the associated subscription. 1309 11. If the "read-default" leaf is set to "permit", then permit the 1310 notification; otherwise, drop the notification for the 1311 associated subscription. 1313 3.5. Data Model Definitions 1314 3.5.1. Data Organization 1316 The following diagram highlights the contents and structure of the 1317 NACM YANG module. 1319 module: ietf-netconf-acm 1320 +--rw nacm 1321 +--rw enable-nacm? boolean 1322 +--rw read-default? action-type 1323 +--rw write-default? action-type 1324 +--rw exec-default? action-type 1325 +--rw enable-external-groups? boolean 1326 +--ro denied-operations yang:zero-based-counter32 1327 +--ro denied-data-writes yang:zero-based-counter32 1328 +--ro denied-notifications yang:zero-based-counter32 1329 +--rw groups 1330 | +--rw group* [name] 1331 | +--rw name group-name-type 1332 | +--rw user-name* user-name-type 1333 +--rw rule-list* [name] 1334 +--rw name string 1335 +--rw group* union 1336 +--rw rule* [name] 1337 +--rw name string 1338 +--rw module-name? union 1339 +--rw (rule-type)? 1340 | +--:(protocol-operation) 1341 | | +--rw rpc-name? union 1342 | +--:(notification) 1343 | | +--rw notification-name? union 1344 | +--:(data-node) 1345 | +--rw path node-instance-identifier 1346 +--rw access-operations? union 1347 +--rw action action-type 1348 +--rw comment? string 1350 3.5.2. YANG Module 1352 The following YANG module specifies the normative NETCONF content 1353 that MUST by supported by the server. 1355 The "ietf-netconf-acm" YANG module imports typedefs from [RFC6991]. 1357 file "ietf-netconf-acm@2017-09-13.yang" 1358 module ietf-netconf-acm { 1360 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm"; 1361 prefix "nacm"; 1363 import ietf-yang-types { 1364 prefix yang; 1365 } 1367 organization 1368 "IETF NETCONF (Network Configuration) Working Group"; 1370 contact 1371 "WG Web: 1372 WG List: 1374 Author: Andy Bierman 1375 1377 Author: Martin Bjorklund 1378 "; 1380 description 1381 "NETCONF Access Control Model. 1383 Copyright (c) 2012, 2017 IETF Trust and the persons 1384 identified as authors of the code. All rights reserved. 1386 Redistribution and use in source and binary forms, with or 1387 without modification, is permitted pursuant to, and subject 1388 to the license terms contained in, the Simplified BSD 1389 License set forth in Section 4.c of the IETF Trust's 1390 Legal Provisions Relating to IETF Documents 1391 (http://trustee.ietf.org/license-info). 1393 This version of this YANG module is part of RFC XXXX; see 1394 the RFC itself for full legal notices."; 1396 revision "2017-09-13" { 1397 description 1398 "Added support for YANG 1.1 actions and notifications tied to 1399 data nodes. Clarify how NACM extensions can be used by other 1400 data models."; 1401 reference 1402 "RFC XXXX: Network Configuration Protocol (NETCONF) 1403 Access Control Model"; 1404 } 1406 revision "2012-02-22" { 1407 description 1408 "Initial version"; 1409 reference 1410 "RFC 6536: Network Configuration Protocol (NETCONF) 1411 Access Control Model"; 1412 } 1414 /* 1415 * Extension statements 1416 */ 1418 extension default-deny-write { 1419 description 1420 "Used to indicate that the data model node 1421 represents a sensitive security system parameter. 1423 If present, the NETCONF server will only allow the designated 1424 'recovery session' to have write access to the node. An 1425 explicit access control rule is required for all other users. 1427 If the NACM module is used, then it must be enabled (i.e., 1428 /nacm/enable-nacm object equals 'true'), or this extension 1429 is ignored. 1431 The 'default-deny-write' extension MAY appear within a data 1432 definition statement. It is ignored otherwise."; 1433 } 1435 extension default-deny-all { 1436 description 1437 "Used to indicate that the data model node 1438 controls a very sensitive security system parameter. 1440 If present, the NETCONF server will only allow the designated 1441 'recovery session' to have read, write, or execute access to the 1442 node. An explicit access control rule is required for all other 1443 users. 1445 If the NACM module is used, then it must be enabled (i.e., 1446 /nacm/enable-nacm object equals 'true'), or this extension 1447 is ignored. 1449 The 'default-deny-all' extension MAY appear within a data 1450 definition statement, 'rpc' statement, or 'notification' 1451 statement. It is ignored otherwise."; 1452 } 1454 /* 1455 * Derived types 1456 */ 1458 typedef user-name-type { 1459 type string { 1460 length "1..max"; 1461 } 1462 description 1463 "General Purpose Username string."; 1464 } 1466 typedef matchall-string-type { 1467 type string { 1468 pattern '\*'; 1469 } 1470 description 1471 "The string containing a single asterisk '*' is used 1472 to conceptually represent all possible values 1473 for the particular leaf using this data type."; 1474 } 1476 typedef access-operations-type { 1477 type bits { 1478 bit create { 1479 description 1480 "Any protocol operation that creates a 1481 new data node."; 1482 } 1483 bit read { 1484 description 1485 "Any protocol operation or notification that 1486 returns the value of a data node."; 1487 } 1488 bit update { 1489 description 1490 "Any protocol operation that alters an existing 1491 data node."; 1492 } 1493 bit delete { 1494 description 1495 "Any protocol operation that removes a data node."; 1496 } 1497 bit exec { 1498 description 1499 "Execution access to the specified protocol operation."; 1500 } 1501 } 1502 description 1503 "Access Operation."; 1505 } 1507 typedef group-name-type { 1508 type string { 1509 length "1..max"; 1510 pattern '[^\*].*'; 1511 } 1512 description 1513 "Name of administrative group to which 1514 users can be assigned."; 1515 } 1517 typedef action-type { 1518 type enumeration { 1519 enum permit { 1520 description 1521 "Requested action is permitted."; 1522 } 1523 enum deny { 1524 description 1525 "Requested action is denied."; 1526 } 1527 } 1528 description 1529 "Action taken by the server when a particular 1530 rule matches."; 1531 } 1533 typedef node-instance-identifier { 1534 type yang:xpath1.0; 1535 description 1536 "Path expression used to represent a special 1537 data node, action, or notification instance identifier 1538 string. 1540 A node-instance-identifier value is an 1541 unrestricted YANG instance-identifier expression. 1542 All the same rules as an instance-identifier apply 1543 except predicates for keys are optional. If a key 1544 predicate is missing, then the node-instance-identifier 1545 represents all possible server instances for that key. 1547 This XPath expression is evaluated in the following context: 1549 o The set of namespace declarations are those in scope on 1550 the leaf element where this type is used. 1552 o The set of variable bindings contains one variable, 1553 'USER', which contains the name of the user of the current 1554 session. 1556 o The function library is the core function library, but 1557 note that due to the syntax restrictions of an 1558 instance-identifier, no functions are allowed. 1560 o The context node is the root node in the data tree. 1562 The accessible tree includes actions and notifications tied 1563 to data nodes."; 1564 } 1566 /* 1567 * Data definition statements 1568 */ 1570 container nacm { 1571 nacm:default-deny-all; 1573 description 1574 "Parameters for NETCONF Access Control Model."; 1576 leaf enable-nacm { 1577 type boolean; 1578 default true; 1579 description 1580 "Enables or disables all NETCONF access control 1581 enforcement. If 'true', then enforcement 1582 is enabled. If 'false', then enforcement 1583 is disabled."; 1584 } 1586 leaf read-default { 1587 type action-type; 1588 default "permit"; 1589 description 1590 "Controls whether read access is granted if 1591 no appropriate rule is found for a 1592 particular read request."; 1593 } 1595 leaf write-default { 1596 type action-type; 1597 default "deny"; 1598 description 1599 "Controls whether create, update, or delete access 1600 is granted if no appropriate rule is found for a 1601 particular write request."; 1602 } 1604 leaf exec-default { 1605 type action-type; 1606 default "permit"; 1607 description 1608 "Controls whether exec access is granted if no appropriate 1609 rule is found for a particular protocol operation request."; 1610 } 1612 leaf enable-external-groups { 1613 type boolean; 1614 default true; 1615 description 1616 "Controls whether the server uses the groups reported by the 1617 NETCONF transport layer when it assigns the user to a set of 1618 NACM groups. If this leaf has the value 'false', any group 1619 names reported by the transport layer are ignored by the 1620 server."; 1621 } 1623 leaf denied-operations { 1624 type yang:zero-based-counter32; 1625 config false; 1626 mandatory true; 1627 description 1628 "Number of times since the server last restarted that a 1629 protocol operation request was denied."; 1630 } 1632 leaf denied-data-writes { 1633 type yang:zero-based-counter32; 1634 config false; 1635 mandatory true; 1636 description 1637 "Number of times since the server last restarted that a 1638 protocol operation request to alter 1639 a configuration datastore was denied."; 1640 } 1642 leaf denied-notifications { 1643 type yang:zero-based-counter32; 1644 config false; 1645 mandatory true; 1646 description 1647 "Number of times since the server last restarted that 1648 a notification was dropped for a subscription because 1649 access to the event type was denied."; 1650 } 1652 container groups { 1653 description 1654 "NETCONF Access Control Groups."; 1656 list group { 1657 key name; 1659 description 1660 "One NACM Group Entry. This list will only contain 1661 configured entries, not any entries learned from 1662 any transport protocols."; 1664 leaf name { 1665 type group-name-type; 1666 description 1667 "Group name associated with this entry."; 1668 } 1670 leaf-list user-name { 1671 type user-name-type; 1672 description 1673 "Each entry identifies the username of 1674 a member of the group associated with 1675 this entry."; 1676 } 1677 } 1678 } 1680 list rule-list { 1681 key "name"; 1682 ordered-by user; 1683 description 1684 "An ordered collection of access control rules."; 1686 leaf name { 1687 type string { 1688 length "1..max"; 1689 } 1690 description 1691 "Arbitrary name assigned to the rule-list."; 1692 } 1693 leaf-list group { 1694 type union { 1695 type matchall-string-type; 1696 type group-name-type; 1698 } 1699 description 1700 "List of administrative groups that will be 1701 assigned the associated access rights 1702 defined by the 'rule' list. 1704 The string '*' indicates that all groups apply to the 1705 entry."; 1706 } 1708 list rule { 1709 key "name"; 1710 ordered-by user; 1711 description 1712 "One access control rule. 1714 Rules are processed in user-defined order until a match is 1715 found. A rule matches if 'module-name', 'rule-type', and 1716 'access-operations' match the request. If a rule 1717 matches, the 'action' leaf determines if access is granted 1718 or not."; 1720 leaf name { 1721 type string { 1722 length "1..max"; 1723 } 1724 description 1725 "Arbitrary name assigned to the rule."; 1726 } 1728 leaf module-name { 1729 type union { 1730 type matchall-string-type; 1731 type string; 1732 } 1733 default "*"; 1734 description 1735 "Name of the module associated with this rule. 1737 This leaf matches if it has the value '*' or if the 1738 object being accessed is defined in the module with the 1739 specified module name."; 1740 } 1741 choice rule-type { 1742 description 1743 "This choice matches if all leafs present in the rule 1744 match the request. If no leafs are present, the 1745 choice matches all requests."; 1747 case protocol-operation { 1748 leaf rpc-name { 1749 type union { 1750 type matchall-string-type; 1751 type string; 1752 } 1753 description 1754 "This leaf matches if it has the value '*' or if 1755 its value equals the requested protocol operation 1756 name."; 1757 } 1758 } 1759 case notification { 1760 leaf notification-name { 1761 type union { 1762 type matchall-string-type; 1763 type string; 1764 } 1765 description 1766 "This leaf matches if it has the value '*' or if its 1767 value equals the requested notification name."; 1768 } 1769 } 1770 case data-node { 1771 leaf path { 1772 type node-instance-identifier; 1773 mandatory true; 1774 description 1775 "Data Node Instance Identifier associated with the 1776 data node controlled by this rule. 1778 Configuration data or state data instance 1779 identifiers start with a top-level data node. A 1780 complete instance identifier is required for this 1781 type of path value. 1783 The special value '/' refers to all possible 1784 datastore contents."; 1785 } 1786 } 1787 } 1789 leaf access-operations { 1790 type union { 1791 type matchall-string-type; 1792 type access-operations-type; 1793 } 1794 default "*"; 1795 description 1796 "Access operations associated with this rule. 1798 This leaf matches if it has the value '*' or if the 1799 bit corresponding to the requested operation is set."; 1800 } 1802 leaf action { 1803 type action-type; 1804 mandatory true; 1805 description 1806 "The access control action associated with the 1807 rule. If a rule is determined to match a 1808 particular request, then this object is used 1809 to determine whether to permit or deny the 1810 request."; 1811 } 1813 leaf comment { 1814 type string; 1815 description 1816 "A textual description of the access rule."; 1817 } 1818 } 1819 } 1820 } 1821 } 1823 1825 Figure 5 1827 3.6. IANA Considerations 1829 This document reuses the URI for "ietf-netconf-acm" in "The IETF XML 1830 Registry". 1832 This document updates the module registration in the "YANG Module 1833 Names" registry to reference this RFC instead of RFC 6536. Following 1834 the format in [RFC6020], the following has been registered. 1836 Name: ietf-netconf-acm 1837 Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm 1838 Prefix: nacm 1839 reference: RFC XXXX 1841 3.7. Security Considerations 1843 This entire document discusses access control requirements and 1844 mechanisms for restricting NETCONF protocol behavior within a given 1845 session. 1847 This section highlights the issues for an administrator to consider 1848 when configuring a NETCONF server with NACM. 1850 3.7.1. NACM Configuration and Monitoring Considerations 1852 Configuration of the access control system is highly sensitive to 1853 system security. A server may choose not to allow any user 1854 configuration to some portions of it, such as the global security 1855 level or the groups that allowed access to system resources. 1857 By default, NACM enforcement is enabled. By default, "read" access 1858 to all datastore contents is enabled (unless "nacm:default-deny-all" 1859 is specified for the data definition), and "exec" access is enabled 1860 for safe protocol operations. An administrator needs to ensure that 1861 NACM is enabled and also decide if the default access parameters are 1862 set appropriately. Make sure the following data nodes are properly 1863 configured: 1865 o /nacm/enable-nacm (default "true") 1867 o /nacm/read-default (default "permit") 1869 o /nacm/write-default (default "deny") 1871 o /nacm/exec-default (default "permit") 1873 An administrator needs to restrict write access to all configurable 1874 objects within this data model. 1876 If write access is allowed for configuration of access control rules, 1877 then care needs to be taken not to disrupt the access control 1878 enforcement. For example, if the NACM access control rules are 1879 edited directly within the running configuration datastore (i.e., 1880 :writable-running capability is supported and used), then care needs 1881 to be taken not to allow unintended access while the edits are being 1882 done. 1884 An administrator needs to make sure that the translation from a 1885 transport- or implementation-dependent user identity to a NACM 1886 username is unique and correct. This requirement is specified in 1887 detail in Section 2.2 of [RFC6241]. 1889 An administrator needs to be aware that the YANG data structures 1890 representing access control rules (/nacm/rule-list and /nacm/rule- 1891 list/rule) are ordered by the client. The server will evaluate the 1892 access control rules according to their relative conceptual order 1893 within the running configuration datastore. 1895 Note that the /nacm/groups data structure contains the administrative 1896 group names used by the server. These group names may be configured 1897 locally and/or provided through an external protocol, such as RADIUS 1898 [RFC2865][RFC5607]. 1900 An administrator needs to be aware of the security properties of any 1901 external protocol used by the transport layer to determine group 1902 names. For example, if this protocol does not protect against man- 1903 in-the-middle attacks, an attacker might be able to inject group 1904 names that are configured in NACM, so that a user gets more 1905 permissions than it should. In such cases, the administrator may 1906 wish to disable the usage of such group names, by setting /nacm/ 1907 enable-external-groups to "false". 1909 An administrator needs to restrict read access to the following 1910 objects within this data model, as they reveal access control 1911 configuration that could be considered sensitive. 1913 o /nacm/enable-nacm 1915 o /nacm/read-default 1917 o /nacm/write-default 1919 o /nacm/exec-default 1921 o /nacm/enable-external-groups 1923 o /nacm/groups 1925 o /nacm/rule-list 1927 3.7.2. General Configuration Issues 1929 There is a risk that invocation of non-standard protocol operations 1930 will have undocumented side effects. An administrator needs to 1931 construct access control rules such that the configuration datastore 1932 is protected from such side effects. 1934 It is possible for a session with some write access (e.g., allowed to 1935 invoke ), but without any access to a particular 1936 datastore subtree containing sensitive data, to determine the 1937 presence or non-presence of that data. This can be done by 1938 repeatedly issuing some sort of edit request (create, update, or 1939 delete) and possibly receiving "access-denied" errors in response. 1940 These "fishing" attacks can identify the presence or non-presence of 1941 specific sensitive data even without the "error-path" field being 1942 present within the response. 1944 It may be possible for the set of NETCONF capabilities on the server 1945 to change over time. If so, then there is a risk that new protocol 1946 operations, notifications, and/or datastore content have been added 1947 to the device. An administrator needs to be sure the access control 1948 rules are correct for the new content in this case. Mechanisms to 1949 detect NETCONF capability changes on a specific device are outside 1950 the scope of this document. 1952 It is possible that the data model definition itself (e.g., YANG 1953 when-stmt) will help an unauthorized session determine the presence 1954 or even value of sensitive data nodes by examining the presence and 1955 values of different data nodes. 1957 There is a risk that non-standard protocol operations, or even the 1958 standard protocol operation, may return data that "aliases" or 1959 "copies" sensitive data from a different data object. There may 1960 simply be multiple data model definitions that expose or even 1961 configure the same underlying system instrumentation. 1963 A data model may contain external keys (e.g., YANG leafref), which 1964 expose values from a different data structure. An administrator 1965 needs to be aware of sensitive data models that contain leafref 1966 nodes. This entails finding all the leafref objects that "point" at 1967 the sensitive data (i.e., "path-stmt" values) that implicitly or 1968 explicitly include the sensitive data node. 1970 It is beyond the scope of this document to define access control 1971 enforcement procedures for underlying device instrumentation that may 1972 exist to support the NETCONF server operation. An administrator can 1973 identify each protocol operation that the server provides and decide 1974 if it needs any access control applied to it. 1976 This document incorporates the optional use of a recovery session 1977 mechanism, which can be used to bypass access control enforcement in 1978 emergencies, such as NACM configuration errors that disable all 1979 access to the server. The configuration and identification of such a 1980 recovery session mechanism are implementation-specific and outside 1981 the scope of this document. An administrator needs to be aware of 1982 any recovery session mechanisms available on the device and make sure 1983 they are used appropriately. 1985 It is possible for a session to disrupt configuration management, 1986 even without any write access to the configuration, by locking the 1987 datastore. This may be done to ensure all or part of the 1988 configuration remains stable while it is being retrieved, or it may 1989 be done as a "denial-of-service" attack. There is no way for the 1990 server to know the difference. An administrator may wish to restrict 1991 "exec" access to the following protocol operations: 1993 o 1995 o 1997 o 1999 o 2001 3.7.3. Data Model Design Considerations 2003 Designers need to clearly identify any sensitive data, notifications, 2004 or protocol operations defined within a YANG module. For such 2005 definitions, a "nacm:default-deny-write" or "nacm:default-deny-all" 2006 statement ought to be present, in addition to a clear description of 2007 the security risks. 2009 Protocol operations need to be properly documented by the data model 2010 designer, so it is clear to administrators what data nodes (if any) 2011 are affected by the protocol operation and what information (if any) 2012 is returned in the message. 2014 Data models ought to be designed so that different access levels for 2015 input parameters to protocol operations are not required. Use of 2016 generic protocol operations should be avoided, and if different 2017 access levels are needed, separate protocol operations should be 2018 defined instead. 2020 4. References 2022 4.1. Normative References 2024 [I-D.ietf-netmod-revised-datastores] 2025 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2026 and R. Wilton, "Network Management Datastore 2027 Architecture", draft-ietf-netmod-revised-datastores-02 2028 (work in progress), May 2017. 2030 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2031 Requirement Levels", BCP 14, RFC 2119, 2032 DOI 10.17487/RFC2119, March 1997, . 2035 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2036 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2037 . 2039 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2040 the Network Configuration Protocol (NETCONF)", RFC 6020, 2041 DOI 10.17487/RFC6020, October 2010, . 2044 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2045 and A. Bierman, Ed., "Network Configuration Protocol 2046 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2047 . 2049 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2050 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2051 . 2053 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2054 Protocol (HTTP/1.1): Message Syntax and Routing", 2055 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2056 . 2058 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2059 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2060 . 2062 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2063 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2064 . 2066 4.2. Informative References 2068 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2069 "Remote Authentication Dial In User Service (RADIUS)", 2070 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2071 . 2073 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 2074 User Service (RADIUS) Authorization for Network Access 2075 Server (NAS) Management", RFC 5607, DOI 10.17487/RFC5607, 2076 July 2009, . 2078 Appendix A. Change Log 2080 -- RFC Ed.: remove this section before publication. 2082 The NACM issue tracker can be found here: https://github.com/netconf- 2083 wg/rfc6536bis/issues 2085 A.1. v04 to v05 2087 o Clarify NETCONF protocol operation vs added operation via 2088 additional YANG modules 2090 o Change term 'NETCONF transport layer' to 'transport layer' 2092 o Clarify that read access operations are not coupled to specific 2093 protocol opreations 2095 o Update date of YANG module so it matches new revision date 2097 A.2. v03 to v04 2099 o Fix revision date mismatch for extracting YANG module 2101 A.3. v02 to v03 2103 o Clarify NACM YANG extensions for use outside NACM 2105 A.4. v01 to v02 2107 o Corrected section title for changes since RFC 6536. 2109 o Added section 'Mapping New Datastores to NACM'. 2111 o Changed term NETCONF datastore to datastore/ 2113 o Removed text about RESTCONF and a conceptual datastore. 2115 A.5. v00 to v01 2117 o Updated RESTCONF reference 2119 A.6. v00 2121 o Renamed document from draft-bierman-netconf-rfc6536bis-01 to 2122 draft-ietf-netconf-rfc6536bis-00. 2124 Appendix B. Usage Examples 2126 The following XML snippets are provided as examples only, to 2127 demonstrate how NACM can be configured to perform some access control 2128 tasks. 2130 B.1. Example 2132 There needs to be at least one entry in order for any of the 2133 access control rules to be useful. 2135 The following XML shows arbitrary groups and is not intended to 2136 represent any particular use case. 2138 2139 2140 2141 admin 2142 admin 2143 andy 2144 2146 2147 limited 2148 wilma 2149 bam-bam 2150 2152 2153 guest 2154 guest 2155 guest@example.com 2156 2157 2158 2160 This example shows three groups: 2162 admin: The "admin" group contains two users named "admin" and 2163 "andy". 2165 limited: The "limited" group contains two users named "wilma" and 2166 "bam-bam". 2168 guest: The "guest" group contains two users named "guest" and 2169 "guest@example.com". 2171 B.2. Module Rule Example 2173 Module rules are used to control access to all the content defined in 2174 a specific module. A module rule has the leaf set, but 2175 no case in the "rule-type" choice. 2177 2178 2179 guest-acl 2180 guest 2182 2183 deny-ncm 2184 ietf-netconf-monitoring 2185 * 2186 deny 2187 2188 Do not allow guests any access to the NETCONF 2189 monitoring information. 2190 2191 2192 2194 2195 limited-acl 2196 limited 2198 2199 permit-ncm 2200 ietf-netconf-monitoring 2201 read 2202 permit 2203 2204 Allow read access to the NETCONF 2205 monitoring information. 2206 2207 2208 2209 permit-exec 2210 * 2211 exec 2212 permit 2213 2214 Allow invocation of the 2215 supported server operations. 2217 2218 2219 2221 2222 admin-acl 2223 admin 2225 2226 permit-all 2227 * 2228 * 2229 permit 2230 2231 Allow the admin group complete access to all 2232 operations and data. 2233 2234 2235 2236 2238 This example shows four module rules: 2240 deny-ncm: This rule prevents the "guest" group from reading any 2241 monitoring information in the "ietf-netconf-monitoring" YANG 2242 module. 2244 permit-ncm: This rule allows the "limited" group to read the "ietf- 2245 netconf-monitoring" YANG module. 2247 permit-exec: This rule allows the "limited" group to invoke any 2248 protocol operation supported by the server. 2250 permit-all: This rule allows the "admin" group complete access to 2251 all content in the server. No subsequent rule will match for the 2252 "admin" group because of this module rule. 2254 B.3. Protocol Operation Rule Example 2256 Protocol operation rules are used to control access to a specific 2257 protocol operation. 2259 2260 2261 guest-limited-acl 2262 limited 2263 guest 2265 2266 deny-kill-session 2267 ietf-netconf 2268 kill-session 2269 exec 2270 deny 2271 2272 Do not allow the limited or guest group 2273 to kill another session. 2274 2275 2276 2277 deny-delete-config 2278 ietf-netconf 2279 delete-config 2280 exec 2281 deny 2282 2283 Do not allow limited or guest group 2284 to delete any configurations. 2285 2286 2287 2289 2290 limited-acl 2291 limited 2293 2294 permit-edit-config 2295 ietf-netconf 2296 edit-config 2297 exec 2298 permit 2299 2300 Allow the limited group to edit the configuration. 2301 2302 2303 2305 2307 This example shows three protocol operation rules: 2309 deny-kill-session: This rule prevents the "limited" or "guest" 2310 groups from invoking the NETCONF protocol 2311 operation. 2313 deny-delete-config: This rule prevents the "limited" or "guest" 2314 groups from invoking the NETCONF protocol 2315 operation. 2317 permit-edit-config: This rule allows the "limited" group to invoke 2318 the NETCONF protocol operation. This rule will have 2319 no real effect unless the "exec-default" leaf is set to "deny". 2321 B.4. Data Node Rule Example 2323 Data node rules are used to control access to specific (config and 2324 non-config) data nodes within the NETCONF content provided by the 2325 server. 2327 2328 2329 guest-acl 2330 guest 2332 2333 deny-nacm 2334 2335 /n:nacm 2336 2337 * 2338 deny 2339 2340 Deny the guest group any access to the /nacm data. 2341 2342 2343 2345 2346 limited-acl 2347 limited 2349 2350 permit-acme-config 2351 2352 /acme:acme-netconf/acme:config-parameters 2353 2354 2355 read create update delete 2356 2357 permit 2358 2359 Allow the limited group complete access to the acme 2360 NETCONF configuration parameters. Showing long form 2361 of 'access-operations' instead of shorthand. 2362 2363 2364 2366 2367 guest-limited-acl 2368 guest 2369 limited 2371 2372 permit-dummy-interface 2373 2374 /acme:interfaces/acme:interface[acme:name='dummy'] 2375 2376 read update 2377 permit 2378 2379 Allow the limited and guest groups read 2380 and update access to the dummy interface. 2381 2382 2383 2385 2386 admin-acl 2387 admin 2388 2389 permit-interface 2390 2391 /acme:interfaces/acme:interface 2392 2393 * 2394 permit 2395 2396 Allow admin full access to all acme interfaces. 2397 2398 2399 2400 2402 This example shows four data node rules: 2404 deny-nacm: This rule denies the "guest" group any access to the 2405 subtree. Note that the default namespace is only 2406 applicable because this subtree is defined in the same namespace 2407 as the element. 2409 permit-acme-config: This rule gives the "limited" group read-write 2410 access to the acme . 2412 permit-dummy-interface: This rule gives the "limited" and "guest" 2413 groups read-update access to the acme entry named 2414 "dummy". This entry cannot be created or deleted by these groups, 2415 just altered. 2417 permit-interface: This rule gives the "admin" group read-write 2418 access to all acme entries. 2420 B.5. Notification Rule Example 2422 Notification rules are used to control access to a specific 2423 notification event type. 2425 2426 2427 sys-acl 2428 limited 2429 guest 2431 2432 deny-config-change 2433 acme-system 2434 sys-config-change 2435 read 2436 deny 2437 2438 Do not allow the guest or limited groups 2439 to receive config change events. 2440 2441 2442 2443 2445 This example shows one notification rule: 2447 deny-config-change: This rule prevents the "limited" or "guest" 2448 groups from receiving the acme event type. 2450 Authors' Addresses 2452 Andy Bierman 2453 YumaWorks 2454 685 Cochran St. 2455 Suite #160 2456 Simi Valley, CA 93065 2457 USA 2459 EMail: andy@yumaworks.com 2461 Martin Bjorklund 2462 Tail-f Systems 2464 EMail: mbj@tail-f.com