idnits 2.17.1 draft-ietf-netconf-rfc6536bis-03.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 (June 27, 2017) is 2495 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: December 29, 2017 June 27, 2017 8 Network Configuration Protocol (NETCONF) Access Control Model 9 draft-ietf-netconf-rfc6536bis-03 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 December 29, 2017. 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 . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . 20 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. v02 to v03 . . . . . . . . . . . . . . . . . . . . . . . 46 118 A.2. v01 to v02 . . . . . . . . . . . . . . . . . . . . . . . 46 119 A.3. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 46 120 A.4. v00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 121 Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 46 122 B.1. Example . . . . . . . . . . . . . . . . . . . . 46 123 B.2. Module Rule Example . . . . . . . . . . . . . . . . . . . 47 124 B.3. Protocol Operation Rule Example . . . . . . . . . . . . . 49 125 B.4. Data Node Rule Example . . . . . . . . . . . . . . . . . 51 126 B.5. Notification Rule Example . . . . . . . . . . . . . . . . 53 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 129 1. Introduction 131 The NETCONF and RESTCONF protocols do not provide any standard 132 mechanisms to restrict the protocol operations and content that each 133 user is authorized to access. 135 There is a need for interoperable management of the controlled access 136 to administrator-selected portions of the available NETCONF or 137 RESTCONF content within a particular server. 139 This document addresses access control mechanisms for the Operations 140 and Content layers of NETCONF, as defined in [RFC6241], and RESTCONF, 141 as defined in [RFC8040]. It contains three main sections: 143 1. Access Control Design Objectives 145 2. NETCONF Access Control Model (NACM) 146 3. YANG Data Model (ietf-netconf-acm.yang) 148 YANG version 1.1 [RFC7950] adds two new constructs that need special 149 access control handling. The "action" statement is similar to the 150 "rpc" statement, except it is located within a data node. The 151 "notification" statement can also be located within a data node. 153 1.1. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 The following terms are defined in 160 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 162 o datastore 164 o configuration datastore 166 o conventional configuration datastore 168 o candidate configuration datastore 170 o running configuration datastore 172 o startup configuration datastore 174 o operational state datastore 176 o client 178 o server 180 The following terms are defined in [RFC6241] and are not redefined 181 here: 183 o protocol operation 185 o session 187 o user 189 The following terms are defined in [RFC7950] and are not redefined 190 here: 192 o action 193 o data node 195 o data definition statement 197 The following terms are defined in [RFC8040] and are not redefined 198 here: 200 o data resource 202 o datastore resource 204 o operation resource 206 o target resource 208 The following term is defined in [RFC7230] and is not redefined here: 210 o request URI 212 The following terms are used throughout this document: 214 access control: A security feature provided by the server that 215 allows an administrator to restrict access to a subset of all 216 protocol operations and data, based on various criteria. 218 access control model (ACM): A conceptual model used to configure and 219 monitor the access control procedures desired by the administrator 220 to enforce a particular access control policy. 222 access control rule: The criterion used to determine if a particular 223 protocol operation will be permitted or denied. 225 access operation: How a request attempts to access a conceptual 226 object. One of "none", "read", "create", "delete", "update", or 227 "execute". 229 data node hierarchy: The hierarchy of data nodes that identifies the 230 specific "action" or "notification" node in the datastore. 232 recovery session: A special administrative session that is given 233 unlimited NETCONF access and is exempt from all access control 234 enforcement. The mechanism(s) used by a server to control and 235 identify whether or not a session is a recovery session are 236 implementation specific and outside the scope of this document. 238 write access: A shorthand for the "create", "delete", and "update" 239 access operations. 241 1.2. Changes Since RFC 6536 243 The NACM procedures and data model have been updated to support new 244 data modeling capabilities in the version 1.1. of the YANG data 245 modeling language. The "action" and "notification" statements can be 246 used within data nodes to define data-model specific operations and 247 notifications. 249 An important use-case for these new YANG statements is the increased 250 access control granularity that can be achieved over top-level "rpc" 251 and "notification" statements. The new "action" and "notification" 252 statements are used within data nodes, and access to the action or 253 notification can be restricted to specific instances of these data 254 nodes. 256 Support for the RESTCONF protocol has been added. The RESTCONF 257 operations are similar to the NETCONF operations, so a simple mapping 258 to the existing NACM procedures and data model is possible. 260 2. Access Control Design Objectives 262 This section documents the design objectives for the NETCONF Access 263 Control Model presented in Section 3. 265 2.1. Access Control Points 267 NETCONF allows new protocol operations to be added at any time, and 268 the YANG Data Modeling Language supports this feature. It is not 269 possible to design an ACM for NETCONF that only focuses on a static 270 set of protocol operations, like some other protocols. Since few 271 assumptions can be made about an arbitrary protocol operation, the 272 NETCONF architectural server components need to be protected at three 273 conceptual control points. 275 These access control points, described in Figure 1, are as follows: 277 protocol operation: Permission to invoke specific protocol 278 operations. 280 datastore: Permission to read and/or alter specific data nodes 281 within any datastore. 283 notification: Permission to receive specific notification event 284 types. 286 +-------------+ +-------------+ 287 client | protocol | | data node | 288 request --> | operation | -------------> | access | 289 | allowed? | datastore | allowed? | 290 +-------------+ or state +-------------+ 291 data access 293 +----------------+ 294 | notification | 295 event --> | allowed? | 296 +----------------+ 298 Figure 1 300 2.2. Simplicity 302 There is concern that a complicated ACM will not be widely deployed 303 because it is too hard to use. It needs to be easy to do simple 304 things and possible to do complex things, instead of hard to do 305 everything. 307 Configuration of the access control system needs to be as simple as 308 possible. Simple and common tasks need to be easy to configure and 309 require little expertise or domain-specific knowledge. Complex tasks 310 are possible using additional mechanisms, which may require 311 additional expertise. 313 A single set of access control rules ought to be able to control all 314 types of NETCONF protocol operation invocation, all datastore access, 315 and all notification events. 317 Access control ought to be defined with a small and familiar set of 318 permissions, while still allowing full control of datastore access. 320 2.3. Procedural Interface 322 The NETCONF protocol uses a remote procedure call model and an 323 extensible set of protocol operations. Access control for any 324 possible protocol operation is necessary. 326 2.4. Datastore Access 328 It is necessary to control access to specific nodes and subtrees 329 within the datastore, regardless of which protocol operation, 330 standard or proprietary, was used to access the datastore. 332 2.5. Users and Groups 334 It is necessary that access control rules for a single user or a 335 configurable group of users can be configured. 337 The ACM needs to support the concept of administrative groups, to 338 support the well-established distinction between a root account and 339 other types of less-privileged conceptual user accounts. These 340 groups need to be configurable by the administrator. 342 It is necessary that the user-to-group mapping can be delegated to a 343 central server, such as a RADIUS server [RFC2865][RFC5607]. Since 344 authentication is performed by the NETCONF transport layer and RADIUS 345 performs authentication and service authorization at the same time, 346 the underlying NETCONF transport needs to be able to report a set of 347 group names associated with the user to the server. It is necessary 348 that the administrator can disable the usage of these group names 349 within the ACM. 351 2.6. Maintenance 353 It ought to be possible to disable part or all of the access control 354 model enforcement procedures without deleting any access control 355 rules. 357 2.7. Configuration Capabilities 359 Suitable configuration and monitoring mechanisms are needed to allow 360 an administrator to easily manage all aspects of the ACM's behavior. 361 A standard data model, suitable for use with the 362 protocol operation, needs to be available for this purpose. 364 Access control rules to restrict access operations on specific 365 subtrees within the configuration datastore need to be supported. 367 2.8. Identifying Security-Sensitive Content 369 One of the most important aspects of the data model documentation, 370 and biggest concerns during deployment, is the identification of 371 security-sensitive content. This applies to protocol operations in 372 NETCONF, not just data and notifications. 374 It is mandatory for security-sensitive objects to be documented in 375 the Security Considerations section of an RFC. This is nice, but it 376 is not good enough, for the following reasons: 378 o This documentation-only approach forces administrators to study 379 the RFC and determine if there are any potential security risks 380 introduced by a new data model. 382 o If any security risks are identified, then the administrator must 383 study some more RFC text and determine how to mitigate the 384 security risk(s). 386 o The ACM on each server must be configured to mitigate the security 387 risks, e.g., require privileged access to read or write the 388 specific data identified in the Security Considerations section. 390 o If the ACM is not pre-configured, then there will be a time window 391 of vulnerability after the new data model is loaded and before the 392 new access control rules for that data model are configured, 393 enabled, and debugged. 395 Often, the administrator just wants to disable default access to the 396 secure content, so no inadvertent or malicious changes can be made to 397 the server. This allows the default rules to be more lenient, 398 without significantly increasing the security risk. 400 A data model designer needs to be able to use machine-readable 401 statements to identify content that needs to be protected by default. 402 This will allow client and server tools to automatically identify 403 data-model-specific security risks, by denying access to sensitive 404 data unless the user is explicitly authorized to perform the 405 requested access operation. 407 3. NETCONF Access Control Model (NACM) 409 3.1. Introduction 411 This section provides a high-level overview of the access control 412 model structure. It describes the NETCONF protocol message 413 processing model and the conceptual access control requirements 414 within that model. 416 3.1.1. Features 418 The NACM data model provides the following features: 420 o Independent control of remote procedure call (RPC), action, data, 421 and notification access. 423 o Simple access control rules configuration data model that is easy 424 to use. 426 o The concept of an emergency recovery session is supported, but 427 configuration of the server for this purpose is beyond the scope 428 of this document. An emergency recovery session will bypass all 429 access control enforcement, in order to allow it to initialize or 430 repair the NACM configuration. 432 o A simple and familiar set of datastore permissions is used. 434 o Support for YANG security tagging (e.g., "nacm:default-deny-write" 435 statement) allows default security modes to automatically exclude 436 sensitive data. 438 o Separate default access modes for read, write, and execute 439 permissions. 441 o Access control rules are applied to configurable groups of users. 443 o The access control enforcement procedures can be disabled during 444 operation, without deleting any access control rules, in order to 445 debug operational problems. 447 o Access control rules are simple to configure. 449 o The number of denied protocol operation requests and denied 450 datastore write requests can be monitored by the client. 452 o Simple unconstrained YANG instance identifiers are used to 453 configure access control rules for specific data nodes. 455 3.1.2. External Dependencies 457 The NETCONF protocol [RFC6241] is used for network management 458 purposes within this document. 460 The RESTCONF protocol [RFC8040] is used for network management 461 purposes within this document. 463 The YANG Data Modeling Language [RFC7950] is used to define the data 464 models for use with the NETCONF or RESTCONF protocols. YANG is also 465 used to define the data model in this document. 467 3.1.3. Message Processing Model 469 The following diagram shows the conceptual message flow model, 470 including the points at which access control is applied during 471 NETCONF message processing. 473 RESTCONF operations are mapped to the access control model based on 474 the HTTP method and resource class used in the operation. For 475 example, a POST method on a data resource is considered "write data 476 node" access, but a POST method on an operation resource is 477 considered "operation" access. 479 +-------------------------+ 480 | session | 481 | (username) | 482 +-------------------------+ 483 | ^ 484 V | 485 +--------------+ +---------------+ 486 | message | | message | 487 | dispatcher | | generator | 488 +--------------+ +---------------+ 489 | | ^ ^ 490 | V | | 491 | +=============+ | | 492 | | pre-read | | | 493 | | data node | | | 494 | | acc. ctl | | | 495 | +=============+ | | 496 | | | | 497 V V | | 498 +===========+ +-------------+ +----------------+ 499 | operation |---> | reply | | | 500 | acc. ctl | | generator | | generator | 501 +===========+ +-------------+ +----------------+ 502 | ^ ^ ^ 503 V +------+ | | 504 +-----------+ | +=============+ +================+ 505 | operation | | | read | | | 506 | processor |-+ | data node | | access ctl | 507 | | | acc. ctl | | | 508 +-----------+ +=============+ +================+ 509 | | ^ ^ ^ 510 V +----------------+ | | | 511 +===========+ | | | +============+ 512 | write | | | | | pre-read | 513 | data node | | | | | data node | 514 | acc. ctl | -----------+ | | | | acc. ctl | 515 +===========+ | | | | +============+ 516 | | | | | ^ 517 V V V | | | 518 +---------------+ +-------------------+ 519 | configuration | ---> | server | 520 | datastore | | instrumentation | 521 | | <--- | | 522 +---------------+ +-------------------+ 524 Figure 2 526 The following high-level sequence of conceptual processing steps is 527 executed for each received message, if access control 528 enforcement is enabled: 530 o For each active session, access control is applied individually to 531 all messages (except ) received by the 532 server, unless the session is identified as a recovery session. 534 o If the operation defined in [RFC7950] is invoked, then 535 read access is required for all instances in the hierarchy of data 536 nodes that identifies the specific action in the datastore, and 537 execute access is required for the action node. If the user is 538 not authorized to read all the specified data nodes and execute 539 the action, then the request is rejected with an "access-denied" 540 error. 542 o Otherwise, if the user is not authorized to execute the specified 543 protocol operation, then the request is rejected with an "access- 544 denied" error. 546 o If a datastore is accessed by the protocol operation, then the 547 server checks if the client is authorized to access the nodes in 548 the datastore. If the user is not authorized to perform the 549 requested access operation on the requested data, then the request 550 is rejected with an "access-denied" error. 552 The following sequence of conceptual processing steps is executed for 553 each generated notification event, if access control enforcement is 554 enabled: 556 o Server instrumentation generates a notification for a particular 557 subscription. 559 o If the notification statement is specified within a data subtree, 560 as specified in [RFC7950], then read access is required for all 561 instances in the hierarchy of data nodes that identifies the 562 specific notification in the datastore, and read access is 563 required for the notification node. If the user is not authorized 564 to read all the specified data nodes and the notification node, 565 then the notification is dropped for that subscription. 567 o If the notification statement is a top-level statement, the 568 notification access control enforcer checks the notification event 569 type, and if it is one that the user is not authorized to read, 570 then the notification is dropped for that subscription. 572 3.2. Datastore Access 574 The same access control rules apply to all datastores that support 575 NACM, for example, the candidate configuration datastore or the 576 running configuration datastore. 578 All conventional configuration datastores and the operational state 579 datastore are controlled by NACM. Local or remote files or 580 datastores accessed via the parameter are not controlled by 581 NACM. 583 3.2.1. Mapping New Datastores to NACM 585 It is possible that new datastores will be defined over time for use 586 with the NETCONF protocol. NACM MAY be applied to other datastores 587 that have similar access rights as defined in NACM. To apply NACM to 588 a new datastore, the new datastore specification needs to define how 589 it maps to the NACM CRUDX access rights. It is possible only a 590 subset of the NACM access rights would be applicable. For example, 591 only retrieval access control would be needed for a read-only 592 datastore. Operations and access rights not supported by the NACM 593 CRUDX model are outside the scope of this document. A datastore does 594 not need to use NACM, e.g., the datastore specification defines 595 something else, or does not use access control. 597 3.2.2. Access Rights 599 A small set of hard-wired datastore access rights is needed to 600 control access to all possible NETCONF protocol operations, including 601 vendor extensions to the standard protocol operation set. 603 The "CRUDX" model can support all NETCONF protocol operations: 605 o Create: allows the client to add a new data node instance to a 606 datastore. 608 o Read: allows the client to read a data node instance from a 609 datastore or receive the notification event type. 611 o Update: allows the client to update an existing data node instance 612 in a datastore. 614 o Delete: allows the client to delete a data node instance from a 615 datastore. 617 o eXec: allows the client to execute the operation. 619 3.2.3. RESTCONF Methods 621 The RESTCONF protocol utilizes HTTP methods to perform datastore 622 operations, similar to the NETCONF protocol. The NACM procedures 623 were originally written for NETCONF protocol operations so the 624 RESTCONF methods are mapped to NETCONF operations for the purpose of 625 access control processing. The enforcement procedures described 626 within this document apply to both protocols unless explicitly stated 627 otherwise. 629 The request URI needs to be considered when processing RESTCONF 630 requests on data resources: 632 o For HEAD and GET requests, any data nodes which are ancestor nodes 633 of the target resource are considered to be part of the retrieval 634 request for access control purposes. 636 o For PUT, PATCH, and DELETE requests, any data nodes which are 637 ancestor nodes of the target resource are not considered to be 638 part of the edit request for access control purposes. The edit 639 operation for these nodes is considered to be 'none'. The edit 640 begins at the target resource. 642 o For POST requests on data resources, any data nodes which are 643 specified in the request URI, including the target resource, are 644 not considered to be part of the edit request for access control 645 purposes. The edit operation for these nodes is considered to be 646 'none'. The edit begins at a child node of the target resource, 647 specified in the message body. 649 Not all RESTCONF methods are subject to access control. The 650 following table specifies how each method is mapped to NETCONF 651 protocol operations. The value 'none' indicates that NACM is not 652 applied at all to the specific RESTCONF method. 654 +---------+-----------------+---------------------+-----------------+ 655 | method | resource class | NETCONF operation | Edit operation | 656 +---------+-----------------+---------------------+-----------------+ 657 | OPTIONS | all | none | N/A | 658 | HEAD | all | | N/A | 659 | GET | all | | N/A | 660 | POST | datastore, data | | create | 661 | POST | operation | specified operation | N/A | 662 | PUT | data | | create, replace | 663 | PUT | datastore | | replace | 664 | PATCH | data, datastore | | merge | 665 | DELETE | data | | delete | 666 +---------+-----------------+---------------------+-----------------+ 668 Table 1: Mapping RESTCONF Methods to NETCONF 670 3.2.4. and Operations 672 Data nodes to which the client does not have read access are silently 673 omitted from the message. This is done to allow NETCONF 674 filters for and to function properly, instead of 675 causing an "access-denied" error because the filter criteria would 676 otherwise include unauthorized read access to some data nodes. For 677 NETCONF filtering purposes, the selection criteria is applied to the 678 subset of nodes that the user is authorized to read, not the entire 679 datastore. 681 3.2.5. Operation 683 The NACM access rights are not directly coupled to the 684 "operation" attribute, although they are similar. Instead, a NACM 685 access right applies to all protocol operations that would result in 686 a particular access operation to the target datastore. This section 687 describes how these access rights apply to the specific access 688 operations supported by the protocol operation. 690 If the effective access operation is "none" (i.e., default- 691 operation="none") for a particular data node, then no access control 692 is applied to that data node. This is required to allow access to a 693 subtree within a larger data structure. For example, a user may be 694 authorized to create a new "/interfaces/interface" list entry but not 695 be authorized to create or delete its parent container 696 ("/interfaces"). If the "/interfaces" container already exists in 697 the target datastore, then the effective operation will be "none" for 698 the "/interfaces" node if an "/interfaces/interface" list entry is 699 edited. 701 If the protocol operation would result in the creation of a datastore 702 node and the user does not have "create" access permission for that 703 node, the protocol operation is rejected with an "access-denied" 704 error. 706 If the protocol operation would result in the deletion of a datastore 707 node and the user does not have "delete" access permission for that 708 node, the protocol operation is rejected with an "access-denied" 709 error. 711 If the protocol operation would result in the modification of a 712 datastore node and the user does not have "update" access permission 713 for that node, the protocol operation is rejected with an "access- 714 denied" error. 716 A "merge" or "replace" operation may include data nodes 717 that do not alter portions of the existing datastore. For example, a 718 container or list node may be present for naming purposes but does 719 not actually alter the corresponding datastore node. These unaltered 720 data nodes are ignored by the server and do not require any access 721 rights by the client. 723 A "merge" operation may include data nodes but not 724 include particular child data nodes that are present in the 725 datastore. These missing data nodes within the scope of a "merge" 726 operation are ignored by the server and do not require 727 any access rights by the client. 729 The contents of specific restricted datastore nodes MUST NOT be 730 exposed in any elements within the reply. 732 3.2.6. Operation 734 Access control for the protocol operation requires 735 special consideration because the administrator may be replacing the 736 entire target datastore. 738 If the source of the protocol operation is the running 739 configuration datastore and the target is the startup configuration 740 datastore, the client is only required to have permission to execute 741 the protocol operation. 743 Otherwise: 745 o If the source of the operation is a datastore, then 746 data nodes to which the client does not have read access are 747 silently omitted. 749 o If the target of the operation is a datastore, the 750 client needs access to the modified nodes, specifically: 752 * If the protocol operation would result in the creation of a 753 datastore node and the user does not have "create" access 754 permission for that node, the protocol operation is rejected 755 with an "access-denied" error. 757 * If the protocol operation would result in the deletion of a 758 datastore node and the user does not have "delete" access 759 permission for that node, the protocol operation is rejected 760 with an "access-denied" error. 762 * If the protocol operation would result in the modification of a 763 datastore node and the user does not have "update" access 764 permission for that node, the protocol operation is rejected 765 with an "access-denied" error. 767 3.2.7. Operation 769 Access to the protocol operation is denied by 770 default. The "exec-default" leaf does not apply to this protocol 771 operation. Access control rules must be explicitly configured to 772 allow invocation by a non-recovery session. 774 3.2.8. Operation 776 The server MUST determine the exact nodes in the running 777 configuration datastore that are actually different and only check 778 "create", "update", and "delete" access permissions for this set of 779 nodes, which could be empty. 781 For example, if a session can read the entire datastore but only 782 change one leaf, that session needs to be able to edit and commit 783 that one leaf. 785 3.2.9. Operation 787 The client is only required to have permission to execute the 788 protocol operation. No datastore permissions are 789 needed. 791 3.2.10. Operation 793 The operation does not directly alter a datastore. 794 However, it allows one session to disrupt another session that is 795 editing a datastore. 797 Access to the protocol operation is denied by default. 798 The "exec-default" leaf does not apply to this protocol operation. 799 Access control rules must be explicitly configured to allow 800 invocation by a non-recovery session. 802 3.3. Model Components 804 This section defines the conceptual components related to the access 805 control model. 807 3.3.1. Users 809 A "user" is the conceptual entity that is associated with the access 810 permissions granted to a particular session. A user is identified by 811 a string that is unique within the server. 813 As described in [RFC6241], the username string is derived from the 814 transport layer during session establishment. If the transport layer 815 cannot authenticate the user, the session is terminated. 817 3.3.2. Groups 819 Access to a specific NETCONF protocol operation is granted to a 820 session, associated with a group, not a user. 822 A group is identified by its name. All group names are unique within 823 the server. 825 A group member is identified by a username string. 827 The same user can be a member of multiple groups. 829 3.3.3. Emergency Recovery Session 831 The server MAY support a recovery session mechanism, which will 832 bypass all access control enforcement. This is useful for 833 restricting initial access and repairing a broken access control 834 configuration. 836 3.3.4. Global Enforcement Controls 838 There are five global controls that are used to help control how 839 access control is enforced. 841 3.3.4.1. enable-nacm Switch 843 A global "enable-nacm" on/off switch is provided to enable or disable 844 all access control enforcement. When this global switch is set to 845 "true", then all requests are checked against the access control 846 rules and only permitted if configured to allow the specific access 847 request. When this global switch is set to "false", then all access 848 requested are permitted. 850 3.3.4.2. read-default Switch 852 An on/off "read-default" switch is provided to enable or disable 853 default access to receive data in replies and notifications. When 854 the "enable-nacm" global switch is set to "true", then this global 855 switch is relevant if no matching access control rule is found to 856 explicitly permit or deny read access to the requested datastore data 857 or notification event type. 859 When this global switch is set to "permit" and no matching access 860 control rule is found for the datastore read or notification event 861 requested, then access is permitted. 863 When this global switch is set to "deny" and no matching access 864 control rule is found for the datastore read or notification event 865 requested, then access is denied. 867 3.3.4.3. write-default Switch 869 An on/off "write-default" switch is provided to enable or disable 870 default access to alter configuration data. When the "enable-nacm" 871 global switch is set to "true", then this global switch is relevant 872 if no matching access control rule is found to explicitly permit or 873 deny write access to the requested datastore data. 875 When this global switch is set to "permit" and no matching access 876 control rule is found for the datastore write requested, then access 877 is permitted. 879 When this global switch is set to "deny" and no matching access 880 control rule is found for the datastore write requested, then access 881 is denied. 883 3.3.4.4. exec-default Switch 885 An on/off "exec-default" switch is provided to enable or disable 886 default access to execute protocol operations. When the "enable- 887 nacm" global switch is set to "true", then this global switch is 888 relevant if no matching access control rule is found to explicitly 889 permit or deny access to the requested NETCONF protocol operation. 891 When this global switch is set to "permit" and no matching access 892 control rule is found for the NETCONF protocol operation requested, 893 then access is permitted. 895 When this global switch is set to "deny" and no matching access 896 control rule is found for the NETCONF protocol operation requested, 897 then access is denied. 899 3.3.4.5. enable-external-groups Switch 901 When this global switch is set to "true", the group names reported by 902 the NETCONF transport layer for a session are used together with the 903 locally configured group names to determine the access control rules 904 for the session. 906 When this switch is set to "false", the group names reported by the 907 NETCONF transport layer are ignored by NACM. 909 3.3.5. Access Control Rules 911 There are four types of rules available in NACM: 913 module rule: controls access for definitions in a specific YANG 914 module, identified by its name. 916 protocol operation rule: controls access for a specific protocol 917 operation, identified by its YANG module and name. 919 data node rule: controls access for a specific data node, identified 920 by its path location within the conceptual XML document for the 921 data node. 923 notification rule: controls access for a specific notification event 924 type, identified by its YANG module and name. 926 3.4. Access Control Enforcement Procedures 928 There are seven separate phases that need to be addressed, four of 929 which are related to the NETCONF message processing model 930 (Section 3.1.3). In addition, the initial startup mode for a NETCONF 931 server, session establishment, and "access-denied" error-handling 932 procedures also need to be considered. 934 The server MUST use the access control rules in effect at the time it 935 starts processing the message. The same access control rules MUST 936 stay in effect for the processing of the entire message. 938 3.4.1. Initial Operation 940 Upon the very first startup of the NETCONF server, the access control 941 configuration will probably not be present. If it isn't, a server 942 MUST NOT allow any write access to any session role except a recovery 943 session. 945 Access rules are enforced any time a request is initiated from a user 946 session. Access control is not enforced for server-initiated access 947 requests, such as the initial load of the running configuration 948 datastore, during bootup. 950 3.4.2. Session Establishment 952 The access control model applies specifically to the well-formed XML 953 content transferred between a client and a server after session 954 establishment has been completed and after the exchange has 955 been successfully completed. 957 Once session establishment is completed and a user has been 958 authenticated, the NETCONF transport layer reports the username and a 959 possibly empty set of group names associated with the user to the 960 NETCONF server. The NETCONF server will enforce the access control 961 rules, based on the supplied username, group names, and the 962 configuration data stored on the server. 964 3.4.3. "access-denied" Error Handling 966 The "access-denied" error-tag is generated when the access control 967 system denies access to either a request to invoke a protocol 968 operation or a request to perform a particular access operation on 969 the configuration datastore. 971 A server MUST NOT include any information the client is not allowed 972 to read in any elements within the response. 974 3.4.4. Incoming RPC Message Validation 976 The diagram below shows the basic conceptual structure of the access 977 control processing model for incoming NETCONF messages within a 978 server. 980 NETCONF server 981 +------------+ 982 | XML | 983 | message | 984 | dispatcher | 985 +------------+ 986 | 987 | 988 V 989 +------------+ 990 | NC-base NS | 991 | | 992 +------------+ 993 | | | 994 | | +-------------------------+ 995 | +------------+ | 996 V V V 997 +-----------+ +---------------+ +------------+ 998 | Vendor NS | | NC-base NS | | NC-base NS | 999 | | | | | | 1000 +-----------+ +---------------+ +------------+ 1001 | | 1002 | | 1003 V V 1004 +----------------------+ 1005 | | 1006 | configuration | 1007 | datastore | 1008 +----------------------+ 1010 Figure 3 1012 Access control begins with the message dispatcher. 1014 After the server validates the element and determines the 1015 namespace URI and the element name of the protocol operation being 1016 requested, the server verifies that the user is authorized to invoke 1017 the protocol operation. 1019 The server MUST separately authorize every protocol operation by 1020 following these steps: 1022 1. If the "enable-nacm" leaf is set to "false", then the protocol 1023 operation is permitted. 1025 2. If the requesting session is identified as a recovery session, 1026 then the protocol operation is permitted. 1028 3. If the requested operation is the NETCONF 1029 protocol operation, then the protocol operation is permitted. 1031 4. Check all the "group" entries for ones that contain a "user- 1032 name" entry that equals the username for the session making the 1033 request. If the "enable-external-groups" leaf is "true", add to 1034 these groups the set of groups provided by the transport layer. 1036 5. If no groups are found, continue with step 10. 1038 6. Process all rule-list entries, in the order they appear in the 1039 configuration. If a rule-list's "group" leaf-list does not 1040 match any of the user's groups, proceed to the next rule-list 1041 entry. 1043 7. For each rule-list entry found, process all rules, in order, 1044 until a rule that matches the requested access operation is 1045 found. A rule matches if all of the following criteria are met: 1047 * The rule's "module-name" leaf is "*" or equals the name of 1048 the YANG module where the protocol operation is defined. 1050 * The rule does not have a "rule-type" defined or the "rule- 1051 type" is "protocol-operation" and the "rpc-name" is "*" or 1052 equals the name of the requested protocol operation. 1054 * The rule's "access-operations" leaf has the "exec" bit set or 1055 has the special value "*". 1057 8. If a matching rule is found, then the "action" leaf is checked. 1058 If it is equal to "permit", then the protocol operation is 1059 permitted; otherwise, it is denied. 1061 9. At this point, no matching rule was found in any rule-list 1062 entry. 1064 10. If the requested protocol operation is defined in a YANG module 1065 advertised in the server capabilities and the "rpc" statement 1066 contains a "nacm:default-deny-all" statement, then the protocol 1067 operation is denied. 1069 11. If the requested protocol operation is the NETCONF or , then the protocol operation is 1071 denied. 1073 12. If the "exec-default" leaf is set to "permit", then permit the 1074 protocol operation; otherwise, deny the request. 1076 If the user is not authorized to invoke the protocol operation, then 1077 an is generated with the following information: 1079 error-tag: access-denied 1081 error-path: Identifies the requested protocol operation. The 1082 following example represents the protocol operation 1083 in the NETCONF base namespace: 1085 1087 /nc:rpc/nc:edit-config 1088 1090 If a datastore is accessed, either directly or as a side effect of 1091 the protocol operation, then the server MUST intercept the access 1092 operation and make sure the user is authorized to perform the 1093 requested access operation on the specified data, as defined in 1094 Section 3.4.5. 1096 3.4.5. Data Node Access Validation 1098 If a data node within a datastore is accessed, or an action or 1099 notification tied to a data node, then the server MUST ensure that 1100 the user is authorized to perform the requested "read", "create", 1101 "update", "delete", or "execute" access operation on the specified 1102 data node. 1104 If an action is requested to be executed, the server MUST ensure that 1105 the user is authorized to perform the "execute" access operation on 1106 the requested action. 1108 If a notification tied to a data node is generated, the server MUST 1109 ensure that the user is authorized to perform the "read" access 1110 operation on the requested notification. 1112 The data node access request is authorized by following these steps: 1114 1. If the "enable-nacm" leaf is set to "false", then the access 1115 operation is permitted. 1117 2. If the requesting session is identified as a recovery session, 1118 then the access operation is permitted. 1120 3. Check all the "group" entries for ones that contain a "user- 1121 name" entry that equals the username for the session making the 1122 request. If the "enable-external-groups" leaf is "true", add to 1123 these groups the set of groups provided by the transport layer. 1125 4. If no groups are found, continue with step 9. 1127 5. Process all rule-list entries, in the order they appear in the 1128 configuration. If a rule-list's "group" leaf-list does not 1129 match any of the user's groups, proceed to the next rule-list 1130 entry. 1132 6. For each rule-list entry found, process all rules, in order, 1133 until a rule that matches the requested access operation is 1134 found. A rule matches if all of the following criteria are met: 1136 * The rule's "module-name" leaf is "*" or equals the name of 1137 the YANG module where the requested data node is defined. 1139 * The rule does not have a "rule-type" defined or the "rule- 1140 type" is "data-node" and the "path" matches the requested 1141 data node, action node, or notification node. 1143 * For a "read" access operation, the rule's "access-operations" 1144 leaf has the "read" bit set or has the special value "*". 1146 * For a "create" access operation, the rule's "access- 1147 operations" leaf has the "create" bit set or has the special 1148 value "*". 1150 * For a "delete" access operation, the rule's "access- 1151 operations" leaf has the "delete" bit set or has the special 1152 value "*". 1154 * For an "update" access operation, the rule's "access- 1155 operations" leaf has the "update" bit set or has the special 1156 value "*". 1158 * For an "execute" access operation, the rule's "access- 1159 operations" leaf has the "exec" bit set or has the special 1160 value "*". 1162 7. If a matching rule is found, then the "action" leaf is checked. 1163 If it is equal to "permit", then the data node access is 1164 permitted; otherwise, it is denied. For a "read" access 1165 operation, "denied" means that the requested data is not 1166 returned in the reply. 1168 8. At this point, no matching rule was found in any rule-list 1169 entry. 1171 9. For a "read" access operation, if the requested data node is 1172 defined in a YANG module advertised in the server capabilities 1173 and the data definition statement contains a "nacm:default-deny- 1174 all" statement, then the requested data node is not included in 1175 the reply. 1177 10. For a "write" access operation, if the requested data node is 1178 defined in a YANG module advertised in the server capabilities 1179 and the data definition statement contains a "nacm:default-deny- 1180 write" or a "nacm:default-deny-all" statement, then the data 1181 node access request is denied. 1183 11. For a "read" access operation, if the "read-default" leaf is set 1184 to "permit", then include the requested data node in the reply; 1185 otherwise, do not include the requested data node in the reply. 1187 12. For a "write" access operation, if the "write-default" leaf is 1188 set to "permit", then permit the data node access request; 1189 otherwise, deny the request. 1191 13. For an "execute" access operation, if the "exec-default" leaf is 1192 set to "permit", then permit the request; otherwise, deny the 1193 request. 1195 3.4.6. Outgoing Authorization 1197 Configuration of access control rules specifically for descendant 1198 nodes of the notification event type element are outside the scope of 1199 this document. If the user is authorized to receive the notification 1200 event type, then it is also authorized to receive any data it 1201 contains. 1203 If the notification is specified within a data subtree, as specified 1204 in [RFC7950], then read access to the notification is required. 1205 Processing continues as described in Section 3.4.5. 1207 The following figure shows the conceptual message processing model 1208 for outgoing messages. 1210 NETCONF server 1211 +------------+ 1212 | XML | 1213 | message | 1214 | generator | 1215 +------------+ 1216 ^ 1217 | 1218 +----------------+ 1219 | | 1220 | generator | 1221 +----------------+ 1222 ^ 1223 | 1224 +=================+ 1225 | | 1226 | access control | 1227 | | 1228 +=================+ 1229 ^ 1230 | 1231 +------------------------+ 1232 | server instrumentation | 1233 +------------------------+ 1234 | ^ 1235 V | 1236 +----------------------+ 1237 | configuration | 1238 | datastore | 1239 +----------------------+ 1241 Figure 4 1243 The generation of a notification for a specific subscription 1244 [RFC5277] is authorized by following these steps: 1246 1. If the "enable-nacm" leaf is set to "false", then the 1247 notification is permitted. 1249 2. If the session is identified as a recovery session, then the 1250 notification is permitted. 1252 3. If the notification is the NETCONF or 1253 event type [RFC5277], then the 1254 notification is permitted. 1256 4. Check all the "group" entries for ones that contain a "user- 1257 name" entry that equals the username for the session making the 1258 request. If the "enable-external-groups" leaf is "true", add to 1259 these groups the set of groups provided by the transport layer. 1261 5. If no groups are found, continue with step 10. 1263 6. Process all rule-list entries, in the order they appear in the 1264 configuration. If a rule-list's "group" leaf-list does not 1265 match any of the user's groups, proceed to the next rule-list 1266 entry. 1268 7. For each rule-list entry found, process all rules, in order, 1269 until a rule that matches the requested access operation is 1270 found. A rule matches if all of the following criteria are met: 1272 * The rule's "module-name" leaf is "*" or equals the name of 1273 the YANG module where the notification is defined. 1275 * The rule does not have a "rule-type" defined or the "rule- 1276 type" is "notification" and the "notification-name" is "*" or 1277 equals the name of the notification. 1279 * The rule's "access-operations" leaf has the "read" bit set or 1280 has the special value "*". 1282 8. If a matching rule is found, then the "action" leaf is checked. 1283 If it is equal to "permit", then permit the notification; 1284 otherwise, drop the notification for the associated 1285 subscription. 1287 9. Otherwise, no matching rule was found in any rule-list entry. 1289 10. If the requested notification is defined in a YANG module 1290 advertised in the server capabilities and the "notification" 1291 statement contains a "nacm:default-deny-all" statement, then the 1292 notification is dropped for the associated subscription. 1294 11. If the "read-default" leaf is set to "permit", then permit the 1295 notification; otherwise, drop the notification for the 1296 associated subscription. 1298 3.5. Data Model Definitions 1299 3.5.1. Data Organization 1301 The following diagram highlights the contents and structure of the 1302 NACM YANG module. 1304 module: ietf-netconf-acm 1305 +--rw nacm 1306 +--rw enable-nacm? boolean 1307 +--rw read-default? action-type 1308 +--rw write-default? action-type 1309 +--rw exec-default? action-type 1310 +--rw enable-external-groups? boolean 1311 +--ro denied-operations yang:zero-based-counter32 1312 +--ro denied-data-writes yang:zero-based-counter32 1313 +--ro denied-notifications yang:zero-based-counter32 1314 +--rw groups 1315 | +--rw group* [name] 1316 | +--rw name group-name-type 1317 | +--rw user-name* user-name-type 1318 +--rw rule-list* [name] 1319 +--rw name string 1320 +--rw group* union 1321 +--rw rule* [name] 1322 +--rw name string 1323 +--rw module-name? union 1324 +--rw (rule-type)? 1325 | +--:(protocol-operation) 1326 | | +--rw rpc-name? union 1327 | +--:(notification) 1328 | | +--rw notification-name? union 1329 | +--:(data-node) 1330 | +--rw path node-instance-identifier 1331 +--rw access-operations? union 1332 +--rw action action-type 1333 +--rw comment? string 1335 3.5.2. YANG Module 1337 The following YANG module specifies the normative NETCONF content 1338 that MUST by supported by the server. 1340 The "ietf-netconf-acm" YANG module imports typedefs from [RFC6991]. 1342 file "ietf-netconf-acm@2017-05-29.yang" 1343 module ietf-netconf-acm { 1345 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm"; 1346 prefix "nacm"; 1348 import ietf-yang-types { 1349 prefix yang; 1350 } 1352 organization 1353 "IETF NETCONF (Network Configuration) Working Group"; 1355 contact 1356 "WG Web: 1357 WG List: 1359 Author: Andy Bierman 1360 1362 Author: Martin Bjorklund 1363 "; 1365 description 1366 "NETCONF Access Control Model. 1368 Copyright (c) 2012, 2017 IETF Trust and the persons 1369 identified as authors of the code. All rights reserved. 1371 Redistribution and use in source and binary forms, with or 1372 without modification, is permitted pursuant to, and subject 1373 to the license terms contained in, the Simplified BSD 1374 License set forth in Section 4.c of the IETF Trust's 1375 Legal Provisions Relating to IETF Documents 1376 (http://trustee.ietf.org/license-info). 1378 This version of this YANG module is part of RFC XXXX; see 1379 the RFC itself for full legal notices."; 1381 revision "2017-06-27" { 1382 description 1383 "Added support for YANG 1.1 actions and notifications tied to 1384 data nodes. Clarify how NACM extensions can be used by other 1385 data models."; 1386 reference 1387 "RFC XXXX: Network Configuration Protocol (NETCONF) 1388 Access Control Model"; 1389 } 1391 revision "2012-02-22" { 1392 description 1393 "Initial version"; 1394 reference 1395 "RFC 6536: Network Configuration Protocol (NETCONF) 1396 Access Control Model"; 1397 } 1399 /* 1400 * Extension statements 1401 */ 1403 extension default-deny-write { 1404 description 1405 "Used to indicate that the data model node 1406 represents a sensitive security system parameter. 1408 If present, the NETCONF server will only allow the designated 1409 'recovery session' to have write access to the node. An 1410 explicit access control rule is required for all other users. 1412 If the NACM module is used, then it must be enabled (i.e., 1413 /nacm/enable-nacm object equals 'true'), or this extension 1414 is ignored. 1416 The 'default-deny-write' extension MAY appear within a data 1417 definition statement. It is ignored otherwise."; 1418 } 1420 extension default-deny-all { 1421 description 1422 "Used to indicate that the data model node 1423 controls a very sensitive security system parameter. 1425 If present, the NETCONF server will only allow the designated 1426 'recovery session' to have read, write, or execute access to the 1427 node. An explicit access control rule is required for all other 1428 users. 1430 If the NACM module is used, then it must be enabled (i.e., 1431 /nacm/enable-nacm object equals 'true'), or this extension 1432 is ignored. 1434 The 'default-deny-all' extension MAY appear within a data 1435 definition statement, 'rpc' statement, or 'notification' 1436 statement. It is ignored otherwise."; 1437 } 1439 /* 1440 * Derived types 1441 */ 1443 typedef user-name-type { 1444 type string { 1445 length "1..max"; 1446 } 1447 description 1448 "General Purpose Username string."; 1449 } 1451 typedef matchall-string-type { 1452 type string { 1453 pattern '\*'; 1454 } 1455 description 1456 "The string containing a single asterisk '*' is used 1457 to conceptually represent all possible values 1458 for the particular leaf using this data type."; 1459 } 1461 typedef access-operations-type { 1462 type bits { 1463 bit create { 1464 description 1465 "Any protocol operation that creates a 1466 new data node."; 1467 } 1468 bit read { 1469 description 1470 "Any protocol operation or notification that 1471 returns the value of a data node."; 1472 } 1473 bit update { 1474 description 1475 "Any protocol operation that alters an existing 1476 data node."; 1477 } 1478 bit delete { 1479 description 1480 "Any protocol operation that removes a data node."; 1481 } 1482 bit exec { 1483 description 1484 "Execution access to the specified protocol operation."; 1485 } 1486 } 1487 description 1488 "Access Operation."; 1490 } 1492 typedef group-name-type { 1493 type string { 1494 length "1..max"; 1495 pattern '[^\*].*'; 1496 } 1497 description 1498 "Name of administrative group to which 1499 users can be assigned."; 1500 } 1502 typedef action-type { 1503 type enumeration { 1504 enum permit { 1505 description 1506 "Requested action is permitted."; 1507 } 1508 enum deny { 1509 description 1510 "Requested action is denied."; 1511 } 1512 } 1513 description 1514 "Action taken by the server when a particular 1515 rule matches."; 1516 } 1518 typedef node-instance-identifier { 1519 type yang:xpath1.0; 1520 description 1521 "Path expression used to represent a special 1522 data node, action, or notification instance identifier 1523 string. 1525 A node-instance-identifier value is an 1526 unrestricted YANG instance-identifier expression. 1527 All the same rules as an instance-identifier apply 1528 except predicates for keys are optional. If a key 1529 predicate is missing, then the node-instance-identifier 1530 represents all possible server instances for that key. 1532 This XPath expression is evaluated in the following context: 1534 o The set of namespace declarations are those in scope on 1535 the leaf element where this type is used. 1537 o The set of variable bindings contains one variable, 1538 'USER', which contains the name of the user of the current 1539 session. 1541 o The function library is the core function library, but 1542 note that due to the syntax restrictions of an 1543 instance-identifier, no functions are allowed. 1545 o The context node is the root node in the data tree. 1547 The accessible tree includes actions and notifications tied 1548 to data nodes."; 1549 } 1551 /* 1552 * Data definition statements 1553 */ 1555 container nacm { 1556 nacm:default-deny-all; 1558 description 1559 "Parameters for NETCONF Access Control Model."; 1561 leaf enable-nacm { 1562 type boolean; 1563 default true; 1564 description 1565 "Enables or disables all NETCONF access control 1566 enforcement. If 'true', then enforcement 1567 is enabled. If 'false', then enforcement 1568 is disabled."; 1569 } 1571 leaf read-default { 1572 type action-type; 1573 default "permit"; 1574 description 1575 "Controls whether read access is granted if 1576 no appropriate rule is found for a 1577 particular read request."; 1578 } 1580 leaf write-default { 1581 type action-type; 1582 default "deny"; 1583 description 1584 "Controls whether create, update, or delete access 1585 is granted if no appropriate rule is found for a 1586 particular write request."; 1587 } 1589 leaf exec-default { 1590 type action-type; 1591 default "permit"; 1592 description 1593 "Controls whether exec access is granted if no appropriate 1594 rule is found for a particular protocol operation request."; 1595 } 1597 leaf enable-external-groups { 1598 type boolean; 1599 default true; 1600 description 1601 "Controls whether the server uses the groups reported by the 1602 NETCONF transport layer when it assigns the user to a set of 1603 NACM groups. If this leaf has the value 'false', any group 1604 names reported by the transport layer are ignored by the 1605 server."; 1606 } 1608 leaf denied-operations { 1609 type yang:zero-based-counter32; 1610 config false; 1611 mandatory true; 1612 description 1613 "Number of times since the server last restarted that a 1614 protocol operation request was denied."; 1615 } 1617 leaf denied-data-writes { 1618 type yang:zero-based-counter32; 1619 config false; 1620 mandatory true; 1621 description 1622 "Number of times since the server last restarted that a 1623 protocol operation request to alter 1624 a configuration datastore was denied."; 1625 } 1627 leaf denied-notifications { 1628 type yang:zero-based-counter32; 1629 config false; 1630 mandatory true; 1631 description 1632 "Number of times since the server last restarted that 1633 a notification was dropped for a subscription because 1634 access to the event type was denied."; 1635 } 1637 container groups { 1638 description 1639 "NETCONF Access Control Groups."; 1641 list group { 1642 key name; 1644 description 1645 "One NACM Group Entry. This list will only contain 1646 configured entries, not any entries learned from 1647 any transport protocols."; 1649 leaf name { 1650 type group-name-type; 1651 description 1652 "Group name associated with this entry."; 1653 } 1655 leaf-list user-name { 1656 type user-name-type; 1657 description 1658 "Each entry identifies the username of 1659 a member of the group associated with 1660 this entry."; 1661 } 1662 } 1663 } 1665 list rule-list { 1666 key "name"; 1667 ordered-by user; 1668 description 1669 "An ordered collection of access control rules."; 1671 leaf name { 1672 type string { 1673 length "1..max"; 1674 } 1675 description 1676 "Arbitrary name assigned to the rule-list."; 1677 } 1678 leaf-list group { 1679 type union { 1680 type matchall-string-type; 1681 type group-name-type; 1683 } 1684 description 1685 "List of administrative groups that will be 1686 assigned the associated access rights 1687 defined by the 'rule' list. 1689 The string '*' indicates that all groups apply to the 1690 entry."; 1691 } 1693 list rule { 1694 key "name"; 1695 ordered-by user; 1696 description 1697 "One access control rule. 1699 Rules are processed in user-defined order until a match is 1700 found. A rule matches if 'module-name', 'rule-type', and 1701 'access-operations' match the request. If a rule 1702 matches, the 'action' leaf determines if access is granted 1703 or not."; 1705 leaf name { 1706 type string { 1707 length "1..max"; 1708 } 1709 description 1710 "Arbitrary name assigned to the rule."; 1711 } 1713 leaf module-name { 1714 type union { 1715 type matchall-string-type; 1716 type string; 1717 } 1718 default "*"; 1719 description 1720 "Name of the module associated with this rule. 1722 This leaf matches if it has the value '*' or if the 1723 object being accessed is defined in the module with the 1724 specified module name."; 1725 } 1726 choice rule-type { 1727 description 1728 "This choice matches if all leafs present in the rule 1729 match the request. If no leafs are present, the 1730 choice matches all requests."; 1732 case protocol-operation { 1733 leaf rpc-name { 1734 type union { 1735 type matchall-string-type; 1736 type string; 1737 } 1738 description 1739 "This leaf matches if it has the value '*' or if 1740 its value equals the requested protocol operation 1741 name."; 1742 } 1743 } 1744 case notification { 1745 leaf notification-name { 1746 type union { 1747 type matchall-string-type; 1748 type string; 1749 } 1750 description 1751 "This leaf matches if it has the value '*' or if its 1752 value equals the requested notification name."; 1753 } 1754 } 1755 case data-node { 1756 leaf path { 1757 type node-instance-identifier; 1758 mandatory true; 1759 description 1760 "Data Node Instance Identifier associated with the 1761 data node controlled by this rule. 1763 Configuration data or state data instance 1764 identifiers start with a top-level data node. A 1765 complete instance identifier is required for this 1766 type of path value. 1768 The special value '/' refers to all possible 1769 datastore contents."; 1770 } 1771 } 1772 } 1774 leaf access-operations { 1775 type union { 1776 type matchall-string-type; 1777 type access-operations-type; 1778 } 1779 default "*"; 1780 description 1781 "Access operations associated with this rule. 1783 This leaf matches if it has the value '*' or if the 1784 bit corresponding to the requested operation is set."; 1785 } 1787 leaf action { 1788 type action-type; 1789 mandatory true; 1790 description 1791 "The access control action associated with the 1792 rule. If a rule is determined to match a 1793 particular request, then this object is used 1794 to determine whether to permit or deny the 1795 request."; 1796 } 1798 leaf comment { 1799 type string; 1800 description 1801 "A textual description of the access rule."; 1802 } 1803 } 1804 } 1805 } 1806 } 1808 1810 Figure 5 1812 3.6. IANA Considerations 1814 This document reuses the URI for "ietf-netconf-acm" in "The IETF XML 1815 Registry". 1817 This document updates the module registration in the "YANG Module 1818 Names" registry to reference this RFC instead of RFC 6536. Following 1819 the format in [RFC6020], the following has been registered. 1821 Name: ietf-netconf-acm 1822 Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm 1823 Prefix: nacm 1824 reference: RFC XXXX 1826 3.7. Security Considerations 1828 This entire document discusses access control requirements and 1829 mechanisms for restricting NETCONF protocol behavior within a given 1830 session. 1832 This section highlights the issues for an administrator to consider 1833 when configuring a NETCONF server with NACM. 1835 3.7.1. NACM Configuration and Monitoring Considerations 1837 Configuration of the access control system is highly sensitive to 1838 system security. A server may choose not to allow any user 1839 configuration to some portions of it, such as the global security 1840 level or the groups that allowed access to system resources. 1842 By default, NACM enforcement is enabled. By default, "read" access 1843 to all datastore contents is enabled (unless "nacm:default-deny-all" 1844 is specified for the data definition), and "exec" access is enabled 1845 for safe protocol operations. An administrator needs to ensure that 1846 NACM is enabled and also decide if the default access parameters are 1847 set appropriately. Make sure the following data nodes are properly 1848 configured: 1850 o /nacm/enable-nacm (default "true") 1852 o /nacm/read-default (default "permit") 1854 o /nacm/write-default (default "deny") 1856 o /nacm/exec-default (default "permit") 1858 An administrator needs to restrict write access to all configurable 1859 objects within this data model. 1861 If write access is allowed for configuration of access control rules, 1862 then care needs to be taken not to disrupt the access control 1863 enforcement. For example, if the NACM access control rules are 1864 edited directly within the running configuration datastore (i.e., 1865 :writable-running capability is supported and used), then care needs 1866 to be taken not to allow unintended access while the edits are being 1867 done. 1869 An administrator needs to make sure that the translation from a 1870 transport- or implementation-dependent user identity to a NACM 1871 username is unique and correct. This requirement is specified in 1872 detail in Section 2.2 of [RFC6241]. 1874 An administrator needs to be aware that the YANG data structures 1875 representing access control rules (/nacm/rule-list and /nacm/rule- 1876 list/rule) are ordered by the client. The server will evaluate the 1877 access control rules according to their relative conceptual order 1878 within the running configuration datastore. 1880 Note that the /nacm/groups data structure contains the administrative 1881 group names used by the server. These group names may be configured 1882 locally and/or provided through an external protocol, such as RADIUS 1883 [RFC2865][RFC5607]. 1885 An administrator needs to be aware of the security properties of any 1886 external protocol used by the NETCONF transport layer to determine 1887 group names. For example, if this protocol does not protect against 1888 man-in-the-middle attacks, an attacker might be able to inject group 1889 names that are configured in NACM, so that a user gets more 1890 permissions than it should. In such cases, the administrator may 1891 wish to disable the usage of such group names, by setting /nacm/ 1892 enable-external-groups to "false". 1894 An administrator needs to restrict read access to the following 1895 objects within this data model, as they reveal access control 1896 configuration that could be considered sensitive. 1898 o /nacm/enable-nacm 1900 o /nacm/read-default 1902 o /nacm/write-default 1904 o /nacm/exec-default 1906 o /nacm/enable-external-groups 1908 o /nacm/groups 1910 o /nacm/rule-list 1912 3.7.2. General Configuration Issues 1914 There is a risk that invocation of non-standard protocol operations 1915 will have undocumented side effects. An administrator needs to 1916 construct access control rules such that the configuration datastore 1917 is protected from such side effects. 1919 It is possible for a session with some write access (e.g., allowed to 1920 invoke ), but without any access to a particular 1921 datastore subtree containing sensitive data, to determine the 1922 presence or non-presence of that data. This can be done by 1923 repeatedly issuing some sort of edit request (create, update, or 1924 delete) and possibly receiving "access-denied" errors in response. 1925 These "fishing" attacks can identify the presence or non-presence of 1926 specific sensitive data even without the "error-path" field being 1927 present within the response. 1929 It may be possible for the set of NETCONF capabilities on the server 1930 to change over time. If so, then there is a risk that new protocol 1931 operations, notifications, and/or datastore content have been added 1932 to the device. An administrator needs to be sure the access control 1933 rules are correct for the new content in this case. Mechanisms to 1934 detect NETCONF capability changes on a specific device are outside 1935 the scope of this document. 1937 It is possible that the data model definition itself (e.g., YANG 1938 when-stmt) will help an unauthorized session determine the presence 1939 or even value of sensitive data nodes by examining the presence and 1940 values of different data nodes. 1942 There is a risk that non-standard protocol operations, or even the 1943 standard protocol operation, may return data that "aliases" or 1944 "copies" sensitive data from a different data object. There may 1945 simply be multiple data model definitions that expose or even 1946 configure the same underlying system instrumentation. 1948 A data model may contain external keys (e.g., YANG leafref), which 1949 expose values from a different data structure. An administrator 1950 needs to be aware of sensitive data models that contain leafref 1951 nodes. This entails finding all the leafref objects that "point" at 1952 the sensitive data (i.e., "path-stmt" values) that implicitly or 1953 explicitly include the sensitive data node. 1955 It is beyond the scope of this document to define access control 1956 enforcement procedures for underlying device instrumentation that may 1957 exist to support the NETCONF server operation. An administrator can 1958 identify each protocol operation that the server provides and decide 1959 if it needs any access control applied to it. 1961 This document incorporates the optional use of a recovery session 1962 mechanism, which can be used to bypass access control enforcement in 1963 emergencies, such as NACM configuration errors that disable all 1964 access to the server. The configuration and identification of such a 1965 recovery session mechanism are implementation-specific and outside 1966 the scope of this document. An administrator needs to be aware of 1967 any recovery session mechanisms available on the device and make sure 1968 they are used appropriately. 1970 It is possible for a session to disrupt configuration management, 1971 even without any write access to the configuration, by locking the 1972 datastore. This may be done to ensure all or part of the 1973 configuration remains stable while it is being retrieved, or it may 1974 be done as a "denial-of-service" attack. There is no way for the 1975 server to know the difference. An administrator may wish to restrict 1976 "exec" access to the following protocol operations: 1978 o 1980 o 1982 o 1984 o 1986 3.7.3. Data Model Design Considerations 1988 Designers need to clearly identify any sensitive data, notifications, 1989 or protocol operations defined within a YANG module. For such 1990 definitions, a "nacm:default-deny-write" or "nacm:default-deny-all" 1991 statement ought to be present, in addition to a clear description of 1992 the security risks. 1994 Protocol operations need to be properly documented by the data model 1995 designer, so it is clear to administrators what data nodes (if any) 1996 are affected by the protocol operation and what information (if any) 1997 is returned in the message. 1999 Data models ought to be designed so that different access levels for 2000 input parameters to protocol operations are not required. Use of 2001 generic protocol operations should be avoided, and if different 2002 access levels are needed, separate protocol operations should be 2003 defined instead. 2005 4. References 2007 4.1. Normative References 2009 [I-D.ietf-netmod-revised-datastores] 2010 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2011 and R. Wilton, "Network Management Datastore 2012 Architecture", draft-ietf-netmod-revised-datastores-02 2013 (work in progress), May 2017. 2015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2016 Requirement Levels", BCP 14, RFC 2119, 2017 DOI 10.17487/RFC2119, March 1997, 2018 . 2020 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2021 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2022 . 2024 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2025 the Network Configuration Protocol (NETCONF)", RFC 6020, 2026 DOI 10.17487/RFC6020, October 2010, 2027 . 2029 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2030 and A. Bierman, Ed., "Network Configuration Protocol 2031 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2032 . 2034 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2035 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2036 . 2038 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2039 Protocol (HTTP/1.1): Message Syntax and Routing", 2040 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2041 . 2043 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2044 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2045 . 2047 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2048 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2049 . 2051 4.2. Informative References 2053 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2054 "Remote Authentication Dial In User Service (RADIUS)", 2055 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2056 . 2058 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 2059 User Service (RADIUS) Authorization for Network Access 2060 Server (NAS) Management", RFC 5607, DOI 10.17487/RFC5607, 2061 July 2009, . 2063 Appendix A. Change Log 2065 -- RFC Ed.: remove this section before publication. 2067 The NACM issue tracker can be found here: https://github.com/netconf- 2068 wg/rfc6536bis/issues 2070 A.1. v02 to v03 2072 o Clarify NACM YANG extensions for use outside NACM 2074 A.2. v01 to v02 2076 o Corrected section title for changes since RFC 6536. 2078 o Added section 'Mapping New Datastores to NACM'. 2080 o Changed term NETCONF datastore to datastore/ 2082 o Removed text about RESTCONF and a conceptual datastore. 2084 A.3. v00 to v01 2086 o Updated RESTCONF reference 2088 A.4. v00 2090 o Renamed document from draft-bierman-netconf-rfc6536bis-01 to 2091 draft-ietf-netconf-rfc6536bis-00. 2093 Appendix B. Usage Examples 2095 The following XML snippets are provided as examples only, to 2096 demonstrate how NACM can be configured to perform some access control 2097 tasks. 2099 B.1. Example 2101 There needs to be at least one entry in order for any of the 2102 access control rules to be useful. 2104 The following XML shows arbitrary groups and is not intended to 2105 represent any particular use case. 2107 2108 2109 2110 admin 2111 admin 2112 andy 2113 2115 2116 limited 2117 wilma 2118 bam-bam 2119 2121 2122 guest 2123 guest 2124 guest@example.com 2125 2126 2127 2129 This example shows three groups: 2131 admin: The "admin" group contains two users named "admin" and 2132 "andy". 2134 limited: The "limited" group contains two users named "wilma" and 2135 "bam-bam". 2137 guest: The "guest" group contains two users named "guest" and 2138 "guest@example.com". 2140 B.2. Module Rule Example 2142 Module rules are used to control access to all the content defined in 2143 a specific module. A module rule has the leaf set, but 2144 no case in the "rule-type" choice. 2146 2147 2148 guest-acl 2149 guest 2151 2152 deny-ncm 2153 ietf-netconf-monitoring 2154 * 2155 deny 2156 2157 Do not allow guests any access to the NETCONF 2158 monitoring information. 2159 2160 2161 2163 2164 limited-acl 2165 limited 2167 2168 permit-ncm 2169 ietf-netconf-monitoring 2170 read 2171 permit 2172 2173 Allow read access to the NETCONF 2174 monitoring information. 2175 2176 2177 2178 permit-exec 2179 * 2180 exec 2181 permit 2182 2183 Allow invocation of the 2184 supported server operations. 2185 2186 2187 2189 2190 admin-acl 2191 admin 2193 2194 permit-all 2195 * 2196 * 2197 permit 2198 2199 Allow the admin group complete access to all 2200 operations and data. 2201 2202 2203 2204 2206 This example shows four module rules: 2208 deny-ncm: This rule prevents the "guest" group from reading any 2209 monitoring information in the "ietf-netconf-monitoring" YANG 2210 module. 2212 permit-ncm: This rule allows the "limited" group to read the "ietf- 2213 netconf-monitoring" YANG module. 2215 permit-exec: This rule allows the "limited" group to invoke any 2216 protocol operation supported by the server. 2218 permit-all: This rule allows the "admin" group complete access to 2219 all content in the server. No subsequent rule will match for the 2220 "admin" group because of this module rule. 2222 B.3. Protocol Operation Rule Example 2224 Protocol operation rules are used to control access to a specific 2225 protocol operation. 2227 2228 2229 guest-limited-acl 2230 limited 2231 guest 2233 2234 deny-kill-session 2235 ietf-netconf 2236 kill-session 2237 exec 2238 deny 2239 2240 Do not allow the limited or guest group 2241 to kill another session. 2242 2243 2244 2245 deny-delete-config 2246 ietf-netconf 2247 delete-config 2248 exec 2249 deny 2250 2251 Do not allow limited or guest group 2252 to delete any configurations. 2253 2254 2255 2257 2258 limited-acl 2259 limited 2261 2262 permit-edit-config 2263 ietf-netconf 2264 edit-config 2265 exec 2266 permit 2267 2268 Allow the limited group to edit the configuration. 2269 2270 2271 2273 2275 This example shows three protocol operation rules: 2277 deny-kill-session: This rule prevents the "limited" or "guest" 2278 groups from invoking the NETCONF protocol 2279 operation. 2281 deny-delete-config: This rule prevents the "limited" or "guest" 2282 groups from invoking the NETCONF protocol 2283 operation. 2285 permit-edit-config: This rule allows the "limited" group to invoke 2286 the NETCONF protocol operation. This rule will have 2287 no real effect unless the "exec-default" leaf is set to "deny". 2289 B.4. Data Node Rule Example 2291 Data node rules are used to control access to specific (config and 2292 non-config) data nodes within the NETCONF content provided by the 2293 server. 2295 2296 2297 guest-acl 2298 guest 2300 2301 deny-nacm 2302 2303 /n:nacm 2304 2305 * 2306 deny 2307 2308 Deny the guest group any access to the /nacm data. 2309 2310 2311 2313 2314 limited-acl 2315 limited 2317 2318 permit-acme-config 2319 2320 /acme:acme-netconf/acme:config-parameters 2321 2322 2323 read create update delete 2324 2325 permit 2326 2327 Allow the limited group complete access to the acme 2328 NETCONF configuration parameters. Showing long form 2329 of 'access-operations' instead of shorthand. 2330 2331 2332 2334 2335 guest-limited-acl 2336 guest 2337 limited 2339 2340 permit-dummy-interface 2341 2342 /acme:interfaces/acme:interface[acme:name='dummy'] 2343 2344 read update 2345 permit 2346 2347 Allow the limited and guest groups read 2348 and update access to the dummy interface. 2349 2350 2351 2353 2354 admin-acl 2355 admin 2356 2357 permit-interface 2358 2359 /acme:interfaces/acme:interface 2360 2361 * 2362 permit 2363 2364 Allow admin full access to all acme interfaces. 2365 2366 2367 2368 2370 This example shows four data node rules: 2372 deny-nacm: This rule denies the "guest" group any access to the 2373 subtree. Note that the default namespace is only 2374 applicable because this subtree is defined in the same namespace 2375 as the element. 2377 permit-acme-config: This rule gives the "limited" group read-write 2378 access to the acme . 2380 permit-dummy-interface: This rule gives the "limited" and "guest" 2381 groups read-update access to the acme entry named 2382 "dummy". This entry cannot be created or deleted by these groups, 2383 just altered. 2385 permit-interface: This rule gives the "admin" group read-write 2386 access to all acme entries. 2388 B.5. Notification Rule Example 2390 Notification rules are used to control access to a specific 2391 notification event type. 2393 2394 2395 sys-acl 2396 limited 2397 guest 2399 2400 deny-config-change 2401 acme-system 2402 sys-config-change 2403 read 2404 deny 2405 2406 Do not allow the guest or limited groups 2407 to receive config change events. 2408 2409 2410 2411 2413 This example shows one notification rule: 2415 deny-config-change: This rule prevents the "limited" or "guest" 2416 groups from receiving the acme event type. 2418 Authors' Addresses 2420 Andy Bierman 2421 YumaWorks 2422 685 Cochran St. 2423 Suite #160 2424 Simi Valley, CA 93065 2425 USA 2427 EMail: andy@yumaworks.com 2428 Martin Bjorklund 2429 Tail-f Systems 2431 EMail: mbj@tail-f.com