idnits 2.17.1 draft-ietf-netconf-rfc6536bis-02.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 (May 30, 2017) is 2522 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 1, 2017 May 30, 2017 8 Network Configuration Protocol (NETCONF) Access Control Model 9 draft-ietf-netconf-rfc6536bis-02 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 1, 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 . . . . . . . . . . . . . . . . . 40 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. v01 to v02 . . . . . . . . . . . . . . . . . . . . . . . 46 118 A.2. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 46 119 A.3. v00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 120 Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 46 121 B.1. Example . . . . . . . . . . . . . . . . . . . . 46 122 B.2. Module Rule Example . . . . . . . . . . . . . . . . . . . 47 123 B.3. Protocol Operation Rule Example . . . . . . . . . . . . . 49 124 B.4. Data Node Rule Example . . . . . . . . . . . . . . . . . 51 125 B.5. Notification Rule Example . . . . . . . . . . . . . . . . 53 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 128 1. Introduction 130 The NETCONF and RESTCONF protocols do not provide any standard 131 mechanisms to restrict the protocol operations and content that each 132 user is authorized to access. 134 There is a need for interoperable management of the controlled access 135 to administrator-selected portions of the available NETCONF or 136 RESTCONF content within a particular server. 138 This document addresses access control mechanisms for the Operations 139 and Content layers of NETCONF, as defined in [RFC6241], and RESTCONF, 140 as defined in [RFC8040]. It contains three main sections: 142 1. Access Control Design Objectives 144 2. NETCONF Access Control Model (NACM) 145 3. YANG Data Model (ietf-netconf-acm.yang) 147 YANG version 1.1 [RFC7950] adds two new constructs that need special 148 access control handling. The "action" statement is similar to the 149 "rpc" statement, except it is located within a data node. The 150 "notification" statement can also be located within a data node. 152 1.1. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 The following terms are defined in 159 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 161 o datastore 163 o configuration datastore 165 o conventional configuration datastore 167 o candidate configuration datastore 169 o running configuration datastore 171 o startup configuration datastore 173 o operational state datastore 175 o client 177 o server 179 The following terms are defined in [RFC6241] and are not redefined 180 here: 182 o protocol operation 184 o session 186 o user 188 The following terms are defined in [RFC7950] and are not redefined 189 here: 191 o action 192 o data node 194 o data definition statement 196 The following terms are defined in [RFC8040] and are not redefined 197 here: 199 o data resource 201 o datastore resource 203 o operation resource 205 o target resource 207 The following term is defined in [RFC7230] and is not redefined here: 209 o request URI 211 The following terms are used throughout this document: 213 access control: A security feature provided by the server that 214 allows an administrator to restrict access to a subset of all 215 protocol operations and data, based on various criteria. 217 access control model (ACM): A conceptual model used to configure and 218 monitor the access control procedures desired by the administrator 219 to enforce a particular access control policy. 221 access control rule: The criterion used to determine if a particular 222 protocol operation will be permitted or denied. 224 access operation: How a request attempts to access a conceptual 225 object. One of "none", "read", "create", "delete", "update", or 226 "execute". 228 data node hierarchy: The hierarchy of data nodes that identifies the 229 specific "action" or "notification" node in the datastore. 231 recovery session: A special administrative session that is given 232 unlimited NETCONF access and is exempt from all access control 233 enforcement. The mechanism(s) used by a server to control and 234 identify whether or not a session is a recovery session are 235 implementation specific and outside the scope of this document. 237 write access: A shorthand for the "create", "delete", and "update" 238 access operations. 240 1.2. Changes Since RFC 6536 242 The NACM procedures and data model have been updated to support new 243 data modeling capabilities in the version 1.1. of the YANG data 244 modeling language. The "action" and "notification" statements can be 245 used within data nodes to define data-model specific operations and 246 notifications. 248 An important use-case for these new YANG statements is the increased 249 access control granularity that can be achieved over top-level "rpc" 250 and "notification" statements. The new "action" and "notification" 251 statements are used within data nodes, and access to the action or 252 notification can be restricted to specific instances of these data 253 nodes. 255 Support for the RESTCONF protocol has been added. The RESTCONF 256 operations are similar to the NETCONF operations, so a simple mapping 257 to the existing NACM procedures and data model is possible. 259 2. Access Control Design Objectives 261 This section documents the design objectives for the NETCONF Access 262 Control Model presented in Section 3. 264 2.1. Access Control Points 266 NETCONF allows new protocol operations to be added at any time, and 267 the YANG Data Modeling Language supports this feature. It is not 268 possible to design an ACM for NETCONF that only focuses on a static 269 set of protocol operations, like some other protocols. Since few 270 assumptions can be made about an arbitrary protocol operation, the 271 NETCONF architectural server components need to be protected at three 272 conceptual control points. 274 These access control points, described in Figure 1, are as follows: 276 protocol operation: Permission to invoke specific protocol 277 operations. 279 datastore: Permission to read and/or alter specific data nodes 280 within any datastore. 282 notification: Permission to receive specific notification event 283 types. 285 +-------------+ +-------------+ 286 client | protocol | | data node | 287 request --> | operation | -------------> | access | 288 | allowed? | datastore | allowed? | 289 +-------------+ or state +-------------+ 290 data access 292 +----------------+ 293 | notification | 294 event --> | allowed? | 295 +----------------+ 297 Figure 1 299 2.2. Simplicity 301 There is concern that a complicated ACM will not be widely deployed 302 because it is too hard to use. It needs to be easy to do simple 303 things and possible to do complex things, instead of hard to do 304 everything. 306 Configuration of the access control system needs to be as simple as 307 possible. Simple and common tasks need to be easy to configure and 308 require little expertise or domain-specific knowledge. Complex tasks 309 are possible using additional mechanisms, which may require 310 additional expertise. 312 A single set of access control rules ought to be able to control all 313 types of NETCONF protocol operation invocation, all datastore access, 314 and all notification events. 316 Access control ought to be defined with a small and familiar set of 317 permissions, while still allowing full control of datastore access. 319 2.3. Procedural Interface 321 The NETCONF protocol uses a remote procedure call model and an 322 extensible set of protocol operations. Access control for any 323 possible protocol operation is necessary. 325 2.4. Datastore Access 327 It is necessary to control access to specific nodes and subtrees 328 within the datastore, regardless of which protocol operation, 329 standard or proprietary, was used to access the datastore. 331 2.5. Users and Groups 333 It is necessary that access control rules for a single user or a 334 configurable group of users can be configured. 336 The ACM needs to support the concept of administrative groups, to 337 support the well-established distinction between a root account and 338 other types of less-privileged conceptual user accounts. These 339 groups need to be configurable by the administrator. 341 It is necessary that the user-to-group mapping can be delegated to a 342 central server, such as a RADIUS server [RFC2865][RFC5607]. Since 343 authentication is performed by the NETCONF transport layer and RADIUS 344 performs authentication and service authorization at the same time, 345 the underlying NETCONF transport needs to be able to report a set of 346 group names associated with the user to the server. It is necessary 347 that the administrator can disable the usage of these group names 348 within the ACM. 350 2.6. Maintenance 352 It ought to be possible to disable part or all of the access control 353 model enforcement procedures without deleting any access control 354 rules. 356 2.7. Configuration Capabilities 358 Suitable configuration and monitoring mechanisms are needed to allow 359 an administrator to easily manage all aspects of the ACM's behavior. 360 A standard data model, suitable for use with the 361 protocol operation, needs to be available for this purpose. 363 Access control rules to restrict access operations on specific 364 subtrees within the configuration datastore need to be supported. 366 2.8. Identifying Security-Sensitive Content 368 One of the most important aspects of the data model documentation, 369 and biggest concerns during deployment, is the identification of 370 security-sensitive content. This applies to protocol operations in 371 NETCONF, not just data and notifications. 373 It is mandatory for security-sensitive objects to be documented in 374 the Security Considerations section of an RFC. This is nice, but it 375 is not good enough, for the following reasons: 377 o This documentation-only approach forces administrators to study 378 the RFC and determine if there are any potential security risks 379 introduced by a new data model. 381 o If any security risks are identified, then the administrator must 382 study some more RFC text and determine how to mitigate the 383 security risk(s). 385 o The ACM on each server must be configured to mitigate the security 386 risks, e.g., require privileged access to read or write the 387 specific data identified in the Security Considerations section. 389 o If the ACM is not pre-configured, then there will be a time window 390 of vulnerability after the new data model is loaded and before the 391 new access control rules for that data model are configured, 392 enabled, and debugged. 394 Often, the administrator just wants to disable default access to the 395 secure content, so no inadvertent or malicious changes can be made to 396 the server. This allows the default rules to be more lenient, 397 without significantly increasing the security risk. 399 A data model designer needs to be able to use machine-readable 400 statements to identify content that needs to be protected by default. 401 This will allow client and server tools to automatically identify 402 data-model-specific security risks, by denying access to sensitive 403 data unless the user is explicitly authorized to perform the 404 requested access operation. 406 3. NETCONF Access Control Model (NACM) 408 3.1. Introduction 410 This section provides a high-level overview of the access control 411 model structure. It describes the NETCONF protocol message 412 processing model and the conceptual access control requirements 413 within that model. 415 3.1.1. Features 417 The NACM data model provides the following features: 419 o Independent control of remote procedure call (RPC), action, data, 420 and notification access. 422 o Simple access control rules configuration data model that is easy 423 to use. 425 o The concept of an emergency recovery session is supported, but 426 configuration of the server for this purpose is beyond the scope 427 of this document. An emergency recovery session will bypass all 428 access control enforcement, in order to allow it to initialize or 429 repair the NACM configuration. 431 o A simple and familiar set of datastore permissions is used. 433 o Support for YANG security tagging (e.g., "nacm:default-deny-write" 434 statement) allows default security modes to automatically exclude 435 sensitive data. 437 o Separate default access modes for read, write, and execute 438 permissions. 440 o Access control rules are applied to configurable groups of users. 442 o The access control enforcement procedures can be disabled during 443 operation, without deleting any access control rules, in order to 444 debug operational problems. 446 o Access control rules are simple to configure. 448 o The number of denied protocol operation requests and denied 449 datastore write requests can be monitored by the client. 451 o Simple unconstrained YANG instance identifiers are used to 452 configure access control rules for specific data nodes. 454 3.1.2. External Dependencies 456 The NETCONF protocol [RFC6241] is used for network management 457 purposes within this document. 459 The RESTCONF protocol [RFC8040] is used for network management 460 purposes within this document. 462 The YANG Data Modeling Language [RFC7950] is used to define the data 463 models for use with the NETCONF or RESTCONF protocols. YANG is also 464 used to define the data model in this document. 466 3.1.3. Message Processing Model 468 The following diagram shows the conceptual message flow model, 469 including the points at which access control is applied during 470 NETCONF message processing. 472 RESTCONF operations are mapped to the access control model based on 473 the HTTP method and resource class used in the operation. For 474 example, a POST method on a data resource is considered "write data 475 node" access, but a POST method on an operation resource is 476 considered "operation" access. 478 +-------------------------+ 479 | session | 480 | (username) | 481 +-------------------------+ 482 | ^ 483 V | 484 +--------------+ +---------------+ 485 | message | | message | 486 | dispatcher | | generator | 487 +--------------+ +---------------+ 488 | | ^ ^ 489 | V | | 490 | +=============+ | | 491 | | pre-read | | | 492 | | data node | | | 493 | | acc. ctl | | | 494 | +=============+ | | 495 | | | | 496 V V | | 497 +===========+ +-------------+ +----------------+ 498 | operation |---> | reply | | | 499 | acc. ctl | | generator | | generator | 500 +===========+ +-------------+ +----------------+ 501 | ^ ^ ^ 502 V +------+ | | 503 +-----------+ | +=============+ +================+ 504 | operation | | | read | | | 505 | processor |-+ | data node | | access ctl | 506 | | | acc. ctl | | | 507 +-----------+ +=============+ +================+ 508 | | ^ ^ ^ 509 V +----------------+ | | | 510 +===========+ | | | +============+ 511 | write | | | | | pre-read | 512 | data node | | | | | data node | 513 | acc. ctl | -----------+ | | | | acc. ctl | 514 +===========+ | | | | +============+ 515 | | | | | ^ 516 V V V | | | 517 +---------------+ +-------------------+ 518 | configuration | ---> | server | 519 | datastore | | instrumentation | 520 | | <--- | | 521 +---------------+ +-------------------+ 523 Figure 2 525 The following high-level sequence of conceptual processing steps is 526 executed for each received message, if access control 527 enforcement is enabled: 529 o For each active session, access control is applied individually to 530 all messages (except ) received by the 531 server, unless the session is identified as a recovery session. 533 o If the operation defined in [RFC7950] is invoked, then 534 read access is required for all instances in the hierarchy of data 535 nodes that identifies the specific action in the datastore, and 536 execute access is required for the action node. If the user is 537 not authorized to read all the specified data nodes and execute 538 the action, then the request is rejected with an "access-denied" 539 error. 541 o Otherwise, if the user is not authorized to execute the specified 542 protocol operation, then the request is rejected with an "access- 543 denied" error. 545 o If a datastore is accessed by the protocol operation, then the 546 server checks if the client is authorized to access the nodes in 547 the datastore. If the user is not authorized to perform the 548 requested access operation on the requested data, then the request 549 is rejected with an "access-denied" error. 551 The following sequence of conceptual processing steps is executed for 552 each generated notification event, if access control enforcement is 553 enabled: 555 o Server instrumentation generates a notification for a particular 556 subscription. 558 o If the notification statement is specified within a data subtree, 559 as specified in [RFC7950], then read access is required for all 560 instances in the hierarchy of data nodes that identifies the 561 specific notification in the datastore, and read access is 562 required for the notification node. If the user is not authorized 563 to read all the specified data nodes and the notification node, 564 then the notification is dropped for that subscription. 566 o If the notification statement is a top-level statement, the 567 notification access control enforcer checks the notification event 568 type, and if it is one that the user is not authorized to read, 569 then the notification is dropped for that subscription. 571 3.2. Datastore Access 573 The same access control rules apply to all datastores that support 574 NACM, for example, the candidate configuration datastore or the 575 running configuration datastore. 577 All conventional configuration datastores and the operational state 578 datastore are controlled by NACM. Local or remote files or 579 datastores accessed via the parameter are not controlled by 580 NACM. 582 3.2.1. Mapping New Datastores to NACM 584 It is possible that new datastores will be defined over time for use 585 with the NETCONF protocol. NACM MAY be applied to other datastores 586 that have similar access rights as defined in NACM. To apply NACM to 587 a new datastore, the new datastore specification needs to define how 588 it maps to the NACM CRUDX access rights. It is possible only a 589 subset of the NACM access rights would be applicable. For example, 590 only retrieval access control would be needed for a read-only 591 datastore. Operations and access rights not supported by the NACM 592 CRUDX model are outside the scope of this document. A datastore does 593 not need to use NACM, e.g., the datastore specification defines 594 something else, or does not use access control. 596 3.2.2. Access Rights 598 A small set of hard-wired datastore access rights is needed to 599 control access to all possible NETCONF protocol operations, including 600 vendor extensions to the standard protocol operation set. 602 The "CRUDX" model can support all NETCONF protocol operations: 604 o Create: allows the client to add a new data node instance to a 605 datastore. 607 o Read: allows the client to read a data node instance from a 608 datastore or receive the notification event type. 610 o Update: allows the client to update an existing data node instance 611 in a datastore. 613 o Delete: allows the client to delete a data node instance from a 614 datastore. 616 o eXec: allows the client to execute the operation. 618 3.2.3. RESTCONF Methods 620 The RESTCONF protocol utilizes HTTP methods to perform datastore 621 operations, similar to the NETCONF protocol. The NACM procedures 622 were originally written for NETCONF protocol operations so the 623 RESTCONF methods are mapped to NETCONF operations for the purpose of 624 access control processing. The enforcement procedures described 625 within this document apply to both protocols unless explicitly stated 626 otherwise. 628 The request URI needs to be considered when processing RESTCONF 629 requests on data resources: 631 o For HEAD and GET requests, any data nodes which are ancestor nodes 632 of the target resource are considered to be part of the retrieval 633 request for access control purposes. 635 o For PUT, PATCH, and DELETE requests, any data nodes which are 636 ancestor nodes of the target resource are not considered to be 637 part of the edit request for access control purposes. The edit 638 operation for these nodes is considered to be 'none'. The edit 639 begins at the target resource. 641 o For POST requests on data resources, any data nodes which are 642 specified in the request URI, including the target resource, are 643 not considered to be part of the edit request for access control 644 purposes. The edit operation for these nodes is considered to be 645 'none'. The edit begins at a child node of the target resource, 646 specified in the message body. 648 Not all RESTCONF methods are subject to access control. The 649 following table specifies how each method is mapped to NETCONF 650 protocol operations. The value 'none' indicates that NACM is not 651 applied at all to the specific RESTCONF method. 653 +---------+-----------------+---------------------+-----------------+ 654 | method | resource class | NETCONF operation | Edit operation | 655 +---------+-----------------+---------------------+-----------------+ 656 | OPTIONS | all | none | N/A | 657 | HEAD | all | | N/A | 658 | GET | all | | N/A | 659 | POST | datastore, data | | create | 660 | POST | operation | specified operation | N/A | 661 | PUT | data | | create, replace | 662 | PUT | datastore | | replace | 663 | PATCH | data, datastore | | merge | 664 | DELETE | data | | delete | 665 +---------+-----------------+---------------------+-----------------+ 667 Table 1: Mapping RESTCONF Methods to NETCONF 669 3.2.4. and Operations 671 Data nodes to which the client does not have read access are silently 672 omitted from the message. This is done to allow NETCONF 673 filters for and to function properly, instead of 674 causing an "access-denied" error because the filter criteria would 675 otherwise include unauthorized read access to some data nodes. For 676 NETCONF filtering purposes, the selection criteria is applied to the 677 subset of nodes that the user is authorized to read, not the entire 678 datastore. 680 3.2.5. Operation 682 The NACM access rights are not directly coupled to the 683 "operation" attribute, although they are similar. Instead, a NACM 684 access right applies to all protocol operations that would result in 685 a particular access operation to the target datastore. This section 686 describes how these access rights apply to the specific access 687 operations supported by the protocol operation. 689 If the effective access operation is "none" (i.e., default- 690 operation="none") for a particular data node, then no access control 691 is applied to that data node. This is required to allow access to a 692 subtree within a larger data structure. For example, a user may be 693 authorized to create a new "/interfaces/interface" list entry but not 694 be authorized to create or delete its parent container 695 ("/interfaces"). If the "/interfaces" container already exists in 696 the target datastore, then the effective operation will be "none" for 697 the "/interfaces" node if an "/interfaces/interface" list entry is 698 edited. 700 If the protocol operation would result in the creation of a datastore 701 node and the user does not have "create" access permission for that 702 node, the protocol operation is rejected with an "access-denied" 703 error. 705 If the protocol operation would result in the deletion of a datastore 706 node and the user does not have "delete" access permission for that 707 node, the protocol operation is rejected with an "access-denied" 708 error. 710 If the protocol operation would result in the modification of a 711 datastore node and the user does not have "update" access permission 712 for that node, the protocol operation is rejected with an "access- 713 denied" error. 715 A "merge" or "replace" operation may include data nodes 716 that do not alter portions of the existing datastore. For example, a 717 container or list node may be present for naming purposes but does 718 not actually alter the corresponding datastore node. These unaltered 719 data nodes are ignored by the server and do not require any access 720 rights by the client. 722 A "merge" operation may include data nodes but not 723 include particular child data nodes that are present in the 724 datastore. These missing data nodes within the scope of a "merge" 725 operation are ignored by the server and do not require 726 any access rights by the client. 728 The contents of specific restricted datastore nodes MUST NOT be 729 exposed in any elements within the reply. 731 3.2.6. Operation 733 Access control for the protocol operation requires 734 special consideration because the administrator may be replacing the 735 entire target datastore. 737 If the source of the protocol operation is the running 738 configuration datastore and the target is the startup configuration 739 datastore, the client is only required to have permission to execute 740 the protocol operation. 742 Otherwise: 744 o If the source of the operation is a datastore, then 745 data nodes to which the client does not have read access are 746 silently omitted. 748 o If the target of the operation is a datastore, the 749 client needs access to the modified nodes, specifically: 751 * If the protocol operation would result in the creation of a 752 datastore node and the user does not have "create" access 753 permission for that node, the protocol operation is rejected 754 with an "access-denied" error. 756 * If the protocol operation would result in the deletion of a 757 datastore node and the user does not have "delete" access 758 permission for that node, the protocol operation is rejected 759 with an "access-denied" error. 761 * If the protocol operation would result in the modification of a 762 datastore node and the user does not have "update" access 763 permission for that node, the protocol operation is rejected 764 with an "access-denied" error. 766 3.2.7. Operation 768 Access to the protocol operation is denied by 769 default. The "exec-default" leaf does not apply to this protocol 770 operation. Access control rules must be explicitly configured to 771 allow invocation by a non-recovery session. 773 3.2.8. Operation 775 The server MUST determine the exact nodes in the running 776 configuration datastore that are actually different and only check 777 "create", "update", and "delete" access permissions for this set of 778 nodes, which could be empty. 780 For example, if a session can read the entire datastore but only 781 change one leaf, that session needs to be able to edit and commit 782 that one leaf. 784 3.2.9. Operation 786 The client is only required to have permission to execute the 787 protocol operation. No datastore permissions are 788 needed. 790 3.2.10. Operation 792 The operation does not directly alter a datastore. 793 However, it allows one session to disrupt another session that is 794 editing a datastore. 796 Access to the protocol operation is denied by default. 797 The "exec-default" leaf does not apply to this protocol operation. 798 Access control rules must be explicitly configured to allow 799 invocation by a non-recovery session. 801 3.3. Model Components 803 This section defines the conceptual components related to the access 804 control model. 806 3.3.1. Users 808 A "user" is the conceptual entity that is associated with the access 809 permissions granted to a particular session. A user is identified by 810 a string that is unique within the server. 812 As described in [RFC6241], the username string is derived from the 813 transport layer during session establishment. If the transport layer 814 cannot authenticate the user, the session is terminated. 816 3.3.2. Groups 818 Access to a specific NETCONF protocol operation is granted to a 819 session, associated with a group, not a user. 821 A group is identified by its name. All group names are unique within 822 the server. 824 A group member is identified by a username string. 826 The same user can be a member of multiple groups. 828 3.3.3. Emergency Recovery Session 830 The server MAY support a recovery session mechanism, which will 831 bypass all access control enforcement. This is useful for 832 restricting initial access and repairing a broken access control 833 configuration. 835 3.3.4. Global Enforcement Controls 837 There are five global controls that are used to help control how 838 access control is enforced. 840 3.3.4.1. enable-nacm Switch 842 A global "enable-nacm" on/off switch is provided to enable or disable 843 all access control enforcement. When this global switch is set to 844 "true", then all requests are checked against the access control 845 rules and only permitted if configured to allow the specific access 846 request. When this global switch is set to "false", then all access 847 requested are permitted. 849 3.3.4.2. read-default Switch 851 An on/off "read-default" switch is provided to enable or disable 852 default access to receive data in replies and notifications. When 853 the "enable-nacm" global switch is set to "true", then this global 854 switch is relevant if no matching access control rule is found to 855 explicitly permit or deny read access to the requested datastore data 856 or notification event type. 858 When this global switch is set to "permit" and no matching access 859 control rule is found for the datastore read or notification event 860 requested, then access is permitted. 862 When this global switch is set to "deny" and no matching access 863 control rule is found for the datastore read or notification event 864 requested, then access is denied. 866 3.3.4.3. write-default Switch 868 An on/off "write-default" switch is provided to enable or disable 869 default access to alter configuration data. When the "enable-nacm" 870 global switch is set to "true", then this global switch is relevant 871 if no matching access control rule is found to explicitly permit or 872 deny write access to the requested datastore data. 874 When this global switch is set to "permit" and no matching access 875 control rule is found for the datastore write requested, then access 876 is permitted. 878 When this global switch is set to "deny" and no matching access 879 control rule is found for the datastore write requested, then access 880 is denied. 882 3.3.4.4. exec-default Switch 884 An on/off "exec-default" switch is provided to enable or disable 885 default access to execute protocol operations. When the "enable- 886 nacm" global switch is set to "true", then this global switch is 887 relevant if no matching access control rule is found to explicitly 888 permit or deny access to the requested NETCONF protocol operation. 890 When this global switch is set to "permit" and no matching access 891 control rule is found for the NETCONF protocol operation requested, 892 then access is permitted. 894 When this global switch is set to "deny" and no matching access 895 control rule is found for the NETCONF protocol operation requested, 896 then access is denied. 898 3.3.4.5. enable-external-groups Switch 900 When this global switch is set to "true", the group names reported by 901 the NETCONF transport layer for a session are used together with the 902 locally configured group names to determine the access control rules 903 for the session. 905 When this switch is set to "false", the group names reported by the 906 NETCONF transport layer are ignored by NACM. 908 3.3.5. Access Control Rules 910 There are four types of rules available in NACM: 912 module rule: controls access for definitions in a specific YANG 913 module, identified by its name. 915 protocol operation rule: controls access for a specific protocol 916 operation, identified by its YANG module and name. 918 data node rule: controls access for a specific data node, identified 919 by its path location within the conceptual XML document for the 920 data node. 922 notification rule: controls access for a specific notification event 923 type, identified by its YANG module and name. 925 3.4. Access Control Enforcement Procedures 927 There are seven separate phases that need to be addressed, four of 928 which are related to the NETCONF message processing model 929 (Section 3.1.3). In addition, the initial startup mode for a NETCONF 930 server, session establishment, and "access-denied" error-handling 931 procedures also need to be considered. 933 The server MUST use the access control rules in effect at the time it 934 starts processing the message. The same access control rules MUST 935 stay in effect for the processing of the entire message. 937 3.4.1. Initial Operation 939 Upon the very first startup of the NETCONF server, the access control 940 configuration will probably not be present. If it isn't, a server 941 MUST NOT allow any write access to any session role except a recovery 942 session. 944 Access rules are enforced any time a request is initiated from a user 945 session. Access control is not enforced for server-initiated access 946 requests, such as the initial load of the running configuration 947 datastore, during bootup. 949 3.4.2. Session Establishment 951 The access control model applies specifically to the well-formed XML 952 content transferred between a client and a server after session 953 establishment has been completed and after the exchange has 954 been successfully completed. 956 Once session establishment is completed and a user has been 957 authenticated, the NETCONF transport layer reports the username and a 958 possibly empty set of group names associated with the user to the 959 NETCONF server. The NETCONF server will enforce the access control 960 rules, based on the supplied username, group names, and the 961 configuration data stored on the server. 963 3.4.3. "access-denied" Error Handling 965 The "access-denied" error-tag is generated when the access control 966 system denies access to either a request to invoke a protocol 967 operation or a request to perform a particular access operation on 968 the configuration datastore. 970 A server MUST NOT include any information the client is not allowed 971 to read in any elements within the response. 973 3.4.4. Incoming RPC Message Validation 975 The diagram below shows the basic conceptual structure of the access 976 control processing model for incoming NETCONF messages within a 977 server. 979 NETCONF server 980 +------------+ 981 | XML | 982 | message | 983 | dispatcher | 984 +------------+ 985 | 986 | 987 V 988 +------------+ 989 | NC-base NS | 990 | | 991 +------------+ 992 | | | 993 | | +-------------------------+ 994 | +------------+ | 995 V V V 996 +-----------+ +---------------+ +------------+ 997 | Vendor NS | | NC-base NS | | NC-base NS | 998 | | | | | | 999 +-----------+ +---------------+ +------------+ 1000 | | 1001 | | 1002 V V 1003 +----------------------+ 1004 | | 1005 | configuration | 1006 | datastore | 1007 +----------------------+ 1009 Figure 3 1011 Access control begins with the message dispatcher. 1013 After the server validates the element and determines the 1014 namespace URI and the element name of the protocol operation being 1015 requested, the server verifies that the user is authorized to invoke 1016 the protocol operation. 1018 The server MUST separately authorize every protocol operation by 1019 following these steps: 1021 1. If the "enable-nacm" leaf is set to "false", then the protocol 1022 operation is permitted. 1024 2. If the requesting session is identified as a recovery session, 1025 then the protocol operation is permitted. 1027 3. If the requested operation is the NETCONF 1028 protocol operation, then the protocol operation is permitted. 1030 4. Check all the "group" entries for ones that contain a "user- 1031 name" entry that equals the username for the session making the 1032 request. If the "enable-external-groups" leaf is "true", add to 1033 these groups the set of groups provided by the transport layer. 1035 5. If no groups are found, continue with step 10. 1037 6. Process all rule-list entries, in the order they appear in the 1038 configuration. If a rule-list's "group" leaf-list does not 1039 match any of the user's groups, proceed to the next rule-list 1040 entry. 1042 7. For each rule-list entry found, process all rules, in order, 1043 until a rule that matches the requested access operation is 1044 found. A rule matches if all of the following criteria are met: 1046 * The rule's "module-name" leaf is "*" or equals the name of 1047 the YANG module where the protocol operation is defined. 1049 * The rule does not have a "rule-type" defined or the "rule- 1050 type" is "protocol-operation" and the "rpc-name" is "*" or 1051 equals the name of the requested protocol operation. 1053 * The rule's "access-operations" leaf has the "exec" bit set or 1054 has the special value "*". 1056 8. If a matching rule is found, then the "action" leaf is checked. 1057 If it is equal to "permit", then the protocol operation is 1058 permitted; otherwise, it is denied. 1060 9. At this point, no matching rule was found in any rule-list 1061 entry. 1063 10. If the requested protocol operation is defined in a YANG module 1064 advertised in the server capabilities and the "rpc" statement 1065 contains a "nacm:default-deny-all" statement, then the protocol 1066 operation is denied. 1068 11. If the requested protocol operation is the NETCONF or , then the protocol operation is 1070 denied. 1072 12. If the "exec-default" leaf is set to "permit", then permit the 1073 protocol operation; otherwise, deny the request. 1075 If the user is not authorized to invoke the protocol operation, then 1076 an is generated with the following information: 1078 error-tag: access-denied 1080 error-path: Identifies the requested protocol operation. The 1081 following example represents the protocol operation 1082 in the NETCONF base namespace: 1084 1086 /nc:rpc/nc:edit-config 1087 1089 If a datastore is accessed, either directly or as a side effect of 1090 the protocol operation, then the server MUST intercept the access 1091 operation and make sure the user is authorized to perform the 1092 requested access operation on the specified data, as defined in 1093 Section 3.4.5. 1095 3.4.5. Data Node Access Validation 1097 If a data node within a datastore is accessed, or an action or 1098 notification tied to a data node, then the server MUST ensure that 1099 the user is authorized to perform the requested "read", "create", 1100 "update", "delete", or "execute" access operation on the specified 1101 data node. 1103 If an action is requested to be executed, the server MUST ensure that 1104 the user is authorized to perform the "execute" access operation on 1105 the requested action. 1107 If a notification tied to a data node is generated, the server MUST 1108 ensure that the user is authorized to perform the "read" access 1109 operation on the requested notification. 1111 The data node access request is authorized by following these steps: 1113 1. If the "enable-nacm" leaf is set to "false", then the access 1114 operation is permitted. 1116 2. If the requesting session is identified as a recovery session, 1117 then the access operation is permitted. 1119 3. Check all the "group" entries for ones that contain a "user- 1120 name" entry that equals the username for the session making the 1121 request. If the "enable-external-groups" leaf is "true", add to 1122 these groups the set of groups provided by the transport layer. 1124 4. If no groups are found, continue with step 9. 1126 5. Process all rule-list entries, in the order they appear in the 1127 configuration. If a rule-list's "group" leaf-list does not 1128 match any of the user's groups, proceed to the next rule-list 1129 entry. 1131 6. For each rule-list entry found, process all rules, in order, 1132 until a rule that matches the requested access operation is 1133 found. A rule matches if all of the following criteria are met: 1135 * The rule's "module-name" leaf is "*" or equals the name of 1136 the YANG module where the requested data node is defined. 1138 * The rule does not have a "rule-type" defined or the "rule- 1139 type" is "data-node" and the "path" matches the requested 1140 data node, action node, or notification node. 1142 * For a "read" access operation, the rule's "access-operations" 1143 leaf has the "read" bit set or has the special value "*". 1145 * For a "create" access operation, the rule's "access- 1146 operations" leaf has the "create" bit set or has the special 1147 value "*". 1149 * For a "delete" access operation, the rule's "access- 1150 operations" leaf has the "delete" bit set or has the special 1151 value "*". 1153 * For an "update" access operation, the rule's "access- 1154 operations" leaf has the "update" bit set or has the special 1155 value "*". 1157 * For an "execute" access operation, the rule's "access- 1158 operations" leaf has the "exec" bit set or has the special 1159 value "*". 1161 7. If a matching rule is found, then the "action" leaf is checked. 1162 If it is equal to "permit", then the data node access is 1163 permitted; otherwise, it is denied. For a "read" access 1164 operation, "denied" means that the requested data is not 1165 returned in the reply. 1167 8. At this point, no matching rule was found in any rule-list 1168 entry. 1170 9. For a "read" access operation, if the requested data node is 1171 defined in a YANG module advertised in the server capabilities 1172 and the data definition statement contains a "nacm:default-deny- 1173 all" statement, then the requested data node is not included in 1174 the reply. 1176 10. For a "write" access operation, if the requested data node is 1177 defined in a YANG module advertised in the server capabilities 1178 and the data definition statement contains a "nacm:default-deny- 1179 write" or a "nacm:default-deny-all" statement, then the data 1180 node access request is denied. 1182 11. For a "read" access operation, if the "read-default" leaf is set 1183 to "permit", then include the requested data node in the reply; 1184 otherwise, do not include the requested data node in the reply. 1186 12. For a "write" access operation, if the "write-default" leaf is 1187 set to "permit", then permit the data node access request; 1188 otherwise, deny the request. 1190 13. For an "execute" access operation, if the "exec-default" leaf is 1191 set to "permit", then permit the request; otherwise, deny the 1192 request. 1194 3.4.6. Outgoing Authorization 1196 Configuration of access control rules specifically for descendant 1197 nodes of the notification event type element are outside the scope of 1198 this document. If the user is authorized to receive the notification 1199 event type, then it is also authorized to receive any data it 1200 contains. 1202 If the notification is specified within a data subtree, as specified 1203 in [RFC7950], then read access to the notification is required. 1204 Processing continues as described in Section 3.4.5. 1206 The following figure shows the conceptual message processing model 1207 for outgoing messages. 1209 NETCONF server 1210 +------------+ 1211 | XML | 1212 | message | 1213 | generator | 1214 +------------+ 1215 ^ 1216 | 1217 +----------------+ 1218 | | 1219 | generator | 1220 +----------------+ 1221 ^ 1222 | 1223 +=================+ 1224 | | 1225 | access control | 1226 | | 1227 +=================+ 1228 ^ 1229 | 1230 +------------------------+ 1231 | server instrumentation | 1232 +------------------------+ 1233 | ^ 1234 V | 1235 +----------------------+ 1236 | configuration | 1237 | datastore | 1238 +----------------------+ 1240 Figure 4 1242 The generation of a notification for a specific subscription 1243 [RFC5277] is authorized by following these steps: 1245 1. If the "enable-nacm" leaf is set to "false", then the 1246 notification is permitted. 1248 2. If the session is identified as a recovery session, then the 1249 notification is permitted. 1251 3. If the notification is the NETCONF or 1252 event type [RFC5277], then the 1253 notification is permitted. 1255 4. Check all the "group" entries for ones that contain a "user- 1256 name" entry that equals the username for the session making the 1257 request. If the "enable-external-groups" leaf is "true", add to 1258 these groups the set of groups provided by the transport layer. 1260 5. If no groups are found, continue with step 10. 1262 6. Process all rule-list entries, in the order they appear in the 1263 configuration. If a rule-list's "group" leaf-list does not 1264 match any of the user's groups, proceed to the next rule-list 1265 entry. 1267 7. For each rule-list entry found, process all rules, in order, 1268 until a rule that matches the requested access operation is 1269 found. A rule matches if all of the following criteria are met: 1271 * The rule's "module-name" leaf is "*" or equals the name of 1272 the YANG module where the notification is defined. 1274 * The rule does not have a "rule-type" defined or the "rule- 1275 type" is "notification" and the "notification-name" is "*" or 1276 equals the name of the notification. 1278 * The rule's "access-operations" leaf has the "read" bit set or 1279 has the special value "*". 1281 8. If a matching rule is found, then the "action" leaf is checked. 1282 If it is equal to "permit", then permit the notification; 1283 otherwise, drop the notification for the associated 1284 subscription. 1286 9. Otherwise, no matching rule was found in any rule-list entry. 1288 10. If the requested notification is defined in a YANG module 1289 advertised in the server capabilities and the "notification" 1290 statement contains a "nacm:default-deny-all" statement, then the 1291 notification is dropped for the associated subscription. 1293 11. If the "read-default" leaf is set to "permit", then permit the 1294 notification; otherwise, drop the notification for the 1295 associated subscription. 1297 3.5. Data Model Definitions 1298 3.5.1. Data Organization 1300 The following diagram highlights the contents and structure of the 1301 NACM YANG module. 1303 module: ietf-netconf-acm 1304 +--rw nacm 1305 +--rw enable-nacm? boolean 1306 +--rw read-default? action-type 1307 +--rw write-default? action-type 1308 +--rw exec-default? action-type 1309 +--rw enable-external-groups? boolean 1310 +--ro denied-operations yang:zero-based-counter32 1311 +--ro denied-data-writes yang:zero-based-counter32 1312 +--ro denied-notifications yang:zero-based-counter32 1313 +--rw groups 1314 | +--rw group* [name] 1315 | +--rw name group-name-type 1316 | +--rw user-name* user-name-type 1317 +--rw rule-list* [name] 1318 +--rw name string 1319 +--rw group* union 1320 +--rw rule* [name] 1321 +--rw name string 1322 +--rw module-name? union 1323 +--rw (rule-type)? 1324 | +--:(protocol-operation) 1325 | | +--rw rpc-name? union 1326 | +--:(notification) 1327 | | +--rw notification-name? union 1328 | +--:(data-node) 1329 | +--rw path node-instance-identifier 1330 +--rw access-operations? union 1331 +--rw action action-type 1332 +--rw comment? string 1334 3.5.2. YANG Module 1336 The following YANG module specifies the normative NETCONF content 1337 that MUST by supported by the server. 1339 The "ietf-netconf-acm" YANG module imports typedefs from [RFC6991]. 1341 file "ietf-netconf-acm@2017-05-29.yang" 1342 module ietf-netconf-acm { 1344 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm"; 1345 prefix "nacm"; 1347 import ietf-yang-types { 1348 prefix yang; 1349 } 1351 organization 1352 "IETF NETCONF (Network Configuration) Working Group"; 1354 contact 1355 "WG Web: 1356 WG List: 1358 Author: Andy Bierman 1359 1361 Author: Martin Bjorklund 1362 "; 1364 description 1365 "NETCONF Access Control Model. 1367 Copyright (c) 2012, 2017 IETF Trust and the persons 1368 identified as authors of the code. All rights reserved. 1370 Redistribution and use in source and binary forms, with or 1371 without modification, is permitted pursuant to, and subject 1372 to the license terms contained in, the Simplified BSD 1373 License set forth in Section 4.c of the IETF Trust's 1374 Legal Provisions Relating to IETF Documents 1375 (http://trustee.ietf.org/license-info). 1377 This version of this YANG module is part of RFC XXXX; see 1378 the RFC itself for full legal notices."; 1380 revision "2017-05-29" { 1381 description 1382 "Added support for YANG 1.1 actions and notifications tied to 1383 data nodes."; 1384 reference 1385 "RFC XXXX: Network Configuration Protocol (NETCONF) 1386 Access Control Model"; 1387 } 1389 revision "2012-02-22" { 1390 description 1391 "Initial version"; 1393 reference 1394 "RFC 6536: Network Configuration Protocol (NETCONF) 1395 Access Control Model"; 1396 } 1398 /* 1399 * Extension statements 1400 */ 1402 extension default-deny-write { 1403 description 1404 "Used to indicate that the data model node 1405 represents a sensitive security system parameter. 1407 If present, and the NACM module is enabled (i.e., 1408 /nacm/enable-nacm object equals 'true'), the NETCONF server 1409 will only allow the designated 'recovery session' to have 1410 write access to the node. An explicit access control rule is 1411 required for all other users. 1413 The 'default-deny-write' extension MAY appear within a data 1414 definition statement. It is ignored otherwise."; 1415 } 1417 extension default-deny-all { 1418 description 1419 "Used to indicate that the data model node 1420 controls a very sensitive security system parameter. 1422 If present, and the NACM module is enabled (i.e., 1423 /nacm/enable-nacm object equals 'true'), the NETCONF server 1424 will only allow the designated 'recovery session' to have 1425 read, write, or execute access to the node. An explicit 1426 access control rule is required for all other users. 1428 The 'default-deny-all' extension MAY appear within a data 1429 definition statement, 'rpc' statement, or 'notification' 1430 statement. It is ignored otherwise."; 1431 } 1433 /* 1434 * Derived types 1435 */ 1437 typedef user-name-type { 1438 type string { 1439 length "1..max"; 1440 } 1441 description 1442 "General Purpose Username string."; 1443 } 1445 typedef matchall-string-type { 1446 type string { 1447 pattern '\*'; 1448 } 1449 description 1450 "The string containing a single asterisk '*' is used 1451 to conceptually represent all possible values 1452 for the particular leaf using this data type."; 1453 } 1455 typedef access-operations-type { 1456 type bits { 1457 bit create { 1458 description 1459 "Any protocol operation that creates a 1460 new data node."; 1461 } 1462 bit read { 1463 description 1464 "Any protocol operation or notification that 1465 returns the value of a data node."; 1466 } 1467 bit update { 1468 description 1469 "Any protocol operation that alters an existing 1470 data node."; 1471 } 1472 bit delete { 1473 description 1474 "Any protocol operation that removes a data node."; 1475 } 1476 bit exec { 1477 description 1478 "Execution access to the specified protocol operation."; 1479 } 1480 } 1481 description 1482 "Access Operation."; 1483 } 1485 typedef group-name-type { 1486 type string { 1487 length "1..max"; 1488 pattern '[^\*].*'; 1490 } 1491 description 1492 "Name of administrative group to which 1493 users can be assigned."; 1494 } 1496 typedef action-type { 1497 type enumeration { 1498 enum permit { 1499 description 1500 "Requested action is permitted."; 1501 } 1502 enum deny { 1503 description 1504 "Requested action is denied."; 1505 } 1506 } 1507 description 1508 "Action taken by the server when a particular 1509 rule matches."; 1510 } 1512 typedef node-instance-identifier { 1513 type yang:xpath1.0; 1514 description 1515 "Path expression used to represent a special 1516 data node, action, or notification instance identifier 1517 string. 1519 A node-instance-identifier value is an 1520 unrestricted YANG instance-identifier expression. 1521 All the same rules as an instance-identifier apply 1522 except predicates for keys are optional. If a key 1523 predicate is missing, then the node-instance-identifier 1524 represents all possible server instances for that key. 1526 This XPath expression is evaluated in the following context: 1528 o The set of namespace declarations are those in scope on 1529 the leaf element where this type is used. 1531 o The set of variable bindings contains one variable, 1532 'USER', which contains the name of the user of the current 1533 session. 1535 o The function library is the core function library, but 1536 note that due to the syntax restrictions of an 1537 instance-identifier, no functions are allowed. 1539 o The context node is the root node in the data tree. 1541 The accessible tree includes actions and notifications tied 1542 to data nodes."; 1543 } 1545 /* 1546 * Data definition statements 1547 */ 1549 container nacm { 1550 nacm:default-deny-all; 1552 description 1553 "Parameters for NETCONF Access Control Model."; 1555 leaf enable-nacm { 1556 type boolean; 1557 default true; 1558 description 1559 "Enables or disables all NETCONF access control 1560 enforcement. If 'true', then enforcement 1561 is enabled. If 'false', then enforcement 1562 is disabled."; 1563 } 1565 leaf read-default { 1566 type action-type; 1567 default "permit"; 1568 description 1569 "Controls whether read access is granted if 1570 no appropriate rule is found for a 1571 particular read request."; 1572 } 1574 leaf write-default { 1575 type action-type; 1576 default "deny"; 1577 description 1578 "Controls whether create, update, or delete access 1579 is granted if no appropriate rule is found for a 1580 particular write request."; 1581 } 1583 leaf exec-default { 1584 type action-type; 1585 default "permit"; 1586 description 1587 "Controls whether exec access is granted if no appropriate 1588 rule is found for a particular protocol operation request."; 1589 } 1591 leaf enable-external-groups { 1592 type boolean; 1593 default true; 1594 description 1595 "Controls whether the server uses the groups reported by the 1596 NETCONF transport layer when it assigns the user to a set of 1597 NACM groups. If this leaf has the value 'false', any group 1598 names reported by the transport layer are ignored by the 1599 server."; 1600 } 1602 leaf denied-operations { 1603 type yang:zero-based-counter32; 1604 config false; 1605 mandatory true; 1606 description 1607 "Number of times since the server last restarted that a 1608 protocol operation request was denied."; 1609 } 1611 leaf denied-data-writes { 1612 type yang:zero-based-counter32; 1613 config false; 1614 mandatory true; 1615 description 1616 "Number of times since the server last restarted that a 1617 protocol operation request to alter 1618 a configuration datastore was denied."; 1619 } 1621 leaf denied-notifications { 1622 type yang:zero-based-counter32; 1623 config false; 1624 mandatory true; 1625 description 1626 "Number of times since the server last restarted that 1627 a notification was dropped for a subscription because 1628 access to the event type was denied."; 1629 } 1631 container groups { 1632 description 1633 "NETCONF Access Control Groups."; 1635 list group { 1636 key name; 1638 description 1639 "One NACM Group Entry. This list will only contain 1640 configured entries, not any entries learned from 1641 any transport protocols."; 1643 leaf name { 1644 type group-name-type; 1645 description 1646 "Group name associated with this entry."; 1647 } 1649 leaf-list user-name { 1650 type user-name-type; 1651 description 1652 "Each entry identifies the username of 1653 a member of the group associated with 1654 this entry."; 1655 } 1656 } 1657 } 1659 list rule-list { 1660 key "name"; 1661 ordered-by user; 1662 description 1663 "An ordered collection of access control rules."; 1665 leaf name { 1666 type string { 1667 length "1..max"; 1668 } 1669 description 1670 "Arbitrary name assigned to the rule-list."; 1671 } 1672 leaf-list group { 1673 type union { 1674 type matchall-string-type; 1675 type group-name-type; 1676 } 1677 description 1678 "List of administrative groups that will be 1679 assigned the associated access rights 1680 defined by the 'rule' list. 1682 The string '*' indicates that all groups apply to the 1683 entry."; 1684 } 1686 list rule { 1687 key "name"; 1688 ordered-by user; 1689 description 1690 "One access control rule. 1692 Rules are processed in user-defined order until a match is 1693 found. A rule matches if 'module-name', 'rule-type', and 1694 'access-operations' match the request. If a rule 1695 matches, the 'action' leaf determines if access is granted 1696 or not."; 1698 leaf name { 1699 type string { 1700 length "1..max"; 1701 } 1702 description 1703 "Arbitrary name assigned to the rule."; 1704 } 1706 leaf module-name { 1707 type union { 1708 type matchall-string-type; 1709 type string; 1710 } 1711 default "*"; 1712 description 1713 "Name of the module associated with this rule. 1715 This leaf matches if it has the value '*' or if the 1716 object being accessed is defined in the module with the 1717 specified module name."; 1718 } 1719 choice rule-type { 1720 description 1721 "This choice matches if all leafs present in the rule 1722 match the request. If no leafs are present, the 1723 choice matches all requests."; 1724 case protocol-operation { 1725 leaf rpc-name { 1726 type union { 1727 type matchall-string-type; 1728 type string; 1729 } 1730 description 1731 "This leaf matches if it has the value '*' or if 1732 its value equals the requested protocol operation 1733 name."; 1734 } 1735 } 1736 case notification { 1737 leaf notification-name { 1738 type union { 1739 type matchall-string-type; 1740 type string; 1741 } 1742 description 1743 "This leaf matches if it has the value '*' or if its 1744 value equals the requested notification name."; 1745 } 1746 } 1747 case data-node { 1748 leaf path { 1749 type node-instance-identifier; 1750 mandatory true; 1751 description 1752 "Data Node Instance Identifier associated with the 1753 data node controlled by this rule. 1755 Configuration data or state data instance 1756 identifiers start with a top-level data node. A 1757 complete instance identifier is required for this 1758 type of path value. 1760 The special value '/' refers to all possible 1761 datastore contents."; 1762 } 1763 } 1764 } 1766 leaf access-operations { 1767 type union { 1768 type matchall-string-type; 1769 type access-operations-type; 1770 } 1771 default "*"; 1772 description 1773 "Access operations associated with this rule. 1775 This leaf matches if it has the value '*' or if the 1776 bit corresponding to the requested operation is set."; 1777 } 1778 leaf action { 1779 type action-type; 1780 mandatory true; 1781 description 1782 "The access control action associated with the 1783 rule. If a rule is determined to match a 1784 particular request, then this object is used 1785 to determine whether to permit or deny the 1786 request."; 1787 } 1789 leaf comment { 1790 type string; 1791 description 1792 "A textual description of the access rule."; 1793 } 1794 } 1795 } 1796 } 1797 } 1799 1801 Figure 5 1803 3.6. IANA Considerations 1805 This document reuses the URI for "ietf-netconf-acm" in "The IETF XML 1806 Registry". 1808 This document updates the module registration in the "YANG Module 1809 Names" registry to reference this RFC instead of RFC 6536. Following 1810 the format in [RFC6020], the following has been registered. 1812 Name: ietf-netconf-acm 1813 Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm 1814 Prefix: nacm 1815 reference: RFC XXXX 1817 3.7. Security Considerations 1819 This entire document discusses access control requirements and 1820 mechanisms for restricting NETCONF protocol behavior within a given 1821 session. 1823 This section highlights the issues for an administrator to consider 1824 when configuring a NETCONF server with NACM. 1826 3.7.1. NACM Configuration and Monitoring Considerations 1828 Configuration of the access control system is highly sensitive to 1829 system security. A server may choose not to allow any user 1830 configuration to some portions of it, such as the global security 1831 level or the groups that allowed access to system resources. 1833 By default, NACM enforcement is enabled. By default, "read" access 1834 to all datastore contents is enabled (unless "nacm:default-deny-all" 1835 is specified for the data definition), and "exec" access is enabled 1836 for safe protocol operations. An administrator needs to ensure that 1837 NACM is enabled and also decide if the default access parameters are 1838 set appropriately. Make sure the following data nodes are properly 1839 configured: 1841 o /nacm/enable-nacm (default "true") 1843 o /nacm/read-default (default "permit") 1845 o /nacm/write-default (default "deny") 1847 o /nacm/exec-default (default "permit") 1849 An administrator needs to restrict write access to all configurable 1850 objects within this data model. 1852 If write access is allowed for configuration of access control rules, 1853 then care needs to be taken not to disrupt the access control 1854 enforcement. For example, if the NACM access control rules are 1855 edited directly within the running configuration datastore (i.e., 1856 :writable-running capability is supported and used), then care needs 1857 to be taken not to allow unintended access while the edits are being 1858 done. 1860 An administrator needs to make sure that the translation from a 1861 transport- or implementation-dependent user identity to a NACM 1862 username is unique and correct. This requirement is specified in 1863 detail in Section 2.2 of [RFC6241]. 1865 An administrator needs to be aware that the YANG data structures 1866 representing access control rules (/nacm/rule-list and /nacm/rule- 1867 list/rule) are ordered by the client. The server will evaluate the 1868 access control rules according to their relative conceptual order 1869 within the running configuration datastore. 1871 Note that the /nacm/groups data structure contains the administrative 1872 group names used by the server. These group names may be configured 1873 locally and/or provided through an external protocol, such as RADIUS 1874 [RFC2865][RFC5607]. 1876 An administrator needs to be aware of the security properties of any 1877 external protocol used by the NETCONF transport layer to determine 1878 group names. For example, if this protocol does not protect against 1879 man-in-the-middle attacks, an attacker might be able to inject group 1880 names that are configured in NACM, so that a user gets more 1881 permissions than it should. In such cases, the administrator may 1882 wish to disable the usage of such group names, by setting /nacm/ 1883 enable-external-groups to "false". 1885 An administrator needs to restrict read access to the following 1886 objects within this data model, as they reveal access control 1887 configuration that could be considered sensitive. 1889 o /nacm/enable-nacm 1891 o /nacm/read-default 1893 o /nacm/write-default 1895 o /nacm/exec-default 1897 o /nacm/enable-external-groups 1899 o /nacm/groups 1901 o /nacm/rule-list 1903 3.7.2. General Configuration Issues 1905 There is a risk that invocation of non-standard protocol operations 1906 will have undocumented side effects. An administrator needs to 1907 construct access control rules such that the configuration datastore 1908 is protected from such side effects. 1910 It is possible for a session with some write access (e.g., allowed to 1911 invoke ), but without any access to a particular 1912 datastore subtree containing sensitive data, to determine the 1913 presence or non-presence of that data. This can be done by 1914 repeatedly issuing some sort of edit request (create, update, or 1915 delete) and possibly receiving "access-denied" errors in response. 1916 These "fishing" attacks can identify the presence or non-presence of 1917 specific sensitive data even without the "error-path" field being 1918 present within the response. 1920 It may be possible for the set of NETCONF capabilities on the server 1921 to change over time. If so, then there is a risk that new protocol 1922 operations, notifications, and/or datastore content have been added 1923 to the device. An administrator needs to be sure the access control 1924 rules are correct for the new content in this case. Mechanisms to 1925 detect NETCONF capability changes on a specific device are outside 1926 the scope of this document. 1928 It is possible that the data model definition itself (e.g., YANG 1929 when-stmt) will help an unauthorized session determine the presence 1930 or even value of sensitive data nodes by examining the presence and 1931 values of different data nodes. 1933 There is a risk that non-standard protocol operations, or even the 1934 standard protocol operation, may return data that "aliases" or 1935 "copies" sensitive data from a different data object. There may 1936 simply be multiple data model definitions that expose or even 1937 configure the same underlying system instrumentation. 1939 A data model may contain external keys (e.g., YANG leafref), which 1940 expose values from a different data structure. An administrator 1941 needs to be aware of sensitive data models that contain leafref 1942 nodes. This entails finding all the leafref objects that "point" at 1943 the sensitive data (i.e., "path-stmt" values) that implicitly or 1944 explicitly include the sensitive data node. 1946 It is beyond the scope of this document to define access control 1947 enforcement procedures for underlying device instrumentation that may 1948 exist to support the NETCONF server operation. An administrator can 1949 identify each protocol operation that the server provides and decide 1950 if it needs any access control applied to it. 1952 This document incorporates the optional use of a recovery session 1953 mechanism, which can be used to bypass access control enforcement in 1954 emergencies, such as NACM configuration errors that disable all 1955 access to the server. The configuration and identification of such a 1956 recovery session mechanism are implementation-specific and outside 1957 the scope of this document. An administrator needs to be aware of 1958 any recovery session mechanisms available on the device and make sure 1959 they are used appropriately. 1961 It is possible for a session to disrupt configuration management, 1962 even without any write access to the configuration, by locking the 1963 datastore. This may be done to ensure all or part of the 1964 configuration remains stable while it is being retrieved, or it may 1965 be done as a "denial-of-service" attack. There is no way for the 1966 server to know the difference. An administrator may wish to restrict 1967 "exec" access to the following protocol operations: 1969 o 1971 o 1973 o 1975 o 1977 3.7.3. Data Model Design Considerations 1979 Designers need to clearly identify any sensitive data, notifications, 1980 or protocol operations defined within a YANG module. For such 1981 definitions, a "nacm:default-deny-write" or "nacm:default-deny-all" 1982 statement ought to be present, in addition to a clear description of 1983 the security risks. 1985 Protocol operations need to be properly documented by the data model 1986 designer, so it is clear to administrators what data nodes (if any) 1987 are affected by the protocol operation and what information (if any) 1988 is returned in the message. 1990 Data models ought to be designed so that different access levels for 1991 input parameters to protocol operations are not required. Use of 1992 generic protocol operations should be avoided, and if different 1993 access levels are needed, separate protocol operations should be 1994 defined instead. 1996 4. References 1998 4.1. Normative References 2000 [I-D.ietf-netmod-revised-datastores] 2001 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2002 and R. Wilton, "Network Management Datastore 2003 Architecture", draft-ietf-netmod-revised-datastores-02 2004 (work in progress), May 2017. 2006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2007 Requirement Levels", BCP 14, RFC 2119, 2008 DOI 10.17487/RFC2119, March 1997, 2009 . 2011 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2012 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2013 . 2015 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2016 the Network Configuration Protocol (NETCONF)", RFC 6020, 2017 DOI 10.17487/RFC6020, October 2010, 2018 . 2020 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2021 and A. Bierman, Ed., "Network Configuration Protocol 2022 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2023 . 2025 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2026 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2027 . 2029 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2030 Protocol (HTTP/1.1): Message Syntax and Routing", 2031 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2032 . 2034 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2035 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2036 . 2038 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2039 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2040 . 2042 4.2. Informative References 2044 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2045 "Remote Authentication Dial In User Service (RADIUS)", 2046 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2047 . 2049 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 2050 User Service (RADIUS) Authorization for Network Access 2051 Server (NAS) Management", RFC 5607, DOI 10.17487/RFC5607, 2052 July 2009, . 2054 Appendix A. Change Log 2056 -- RFC Ed.: remove this section before publication. 2058 The NACM issue tracker can be found here: https://github.com/netconf- 2059 wg/rfc6536bis/issues 2061 A.1. v01 to v02 2063 o Corrected section title for changes since RFC 6536. 2065 o Added section 'Mapping New Datastores to NACM'. 2067 o Changed term NETCONF datastore to datastore/ 2069 o Removed text about RESTCONF and a conceptual datastore. 2071 A.2. v00 to v01 2073 o Updated RESTCONF reference 2075 A.3. v00 2077 o Renamed document from draft-bierman-netconf-rfc6536bis-01 to 2078 draft-ietf-netconf-rfc6536bis-00. 2080 Appendix B. Usage Examples 2082 The following XML snippets are provided as examples only, to 2083 demonstrate how NACM can be configured to perform some access control 2084 tasks. 2086 B.1. Example 2088 There needs to be at least one entry in order for any of the 2089 access control rules to be useful. 2091 The following XML shows arbitrary groups and is not intended to 2092 represent any particular use case. 2094 2095 2096 2097 admin 2098 admin 2099 andy 2100 2102 2103 limited 2104 wilma 2105 bam-bam 2106 2108 2109 guest 2110 guest 2111 guest@example.com 2112 2113 2114 2116 This example shows three groups: 2118 admin: The "admin" group contains two users named "admin" and 2119 "andy". 2121 limited: The "limited" group contains two users named "wilma" and 2122 "bam-bam". 2124 guest: The "guest" group contains two users named "guest" and 2125 "guest@example.com". 2127 B.2. Module Rule Example 2129 Module rules are used to control access to all the content defined in 2130 a specific module. A module rule has the leaf set, but 2131 no case in the "rule-type" choice. 2133 2134 2135 guest-acl 2136 guest 2138 2139 deny-ncm 2140 ietf-netconf-monitoring 2141 * 2142 deny 2143 2144 Do not allow guests any access to the NETCONF 2145 monitoring information. 2146 2147 2148 2150 2151 limited-acl 2152 limited 2154 2155 permit-ncm 2156 ietf-netconf-monitoring 2157 read 2158 permit 2159 2160 Allow read access to the NETCONF 2161 monitoring information. 2162 2163 2164 2165 permit-exec 2166 * 2167 exec 2168 permit 2169 2170 Allow invocation of the 2171 supported server operations. 2172 2173 2174 2176 2177 admin-acl 2178 admin 2180 2181 permit-all 2182 * 2183 * 2184 permit 2185 2186 Allow the admin group complete access to all 2187 operations and data. 2188 2189 2190 2191 2193 This example shows four module rules: 2195 deny-ncm: This rule prevents the "guest" group from reading any 2196 monitoring information in the "ietf-netconf-monitoring" YANG 2197 module. 2199 permit-ncm: This rule allows the "limited" group to read the "ietf- 2200 netconf-monitoring" YANG module. 2202 permit-exec: This rule allows the "limited" group to invoke any 2203 protocol operation supported by the server. 2205 permit-all: This rule allows the "admin" group complete access to 2206 all content in the server. No subsequent rule will match for the 2207 "admin" group because of this module rule. 2209 B.3. Protocol Operation Rule Example 2211 Protocol operation rules are used to control access to a specific 2212 protocol operation. 2214 2215 2216 guest-limited-acl 2217 limited 2218 guest 2220 2221 deny-kill-session 2222 ietf-netconf 2223 kill-session 2224 exec 2225 deny 2226 2227 Do not allow the limited or guest group 2228 to kill another session. 2229 2230 2231 2232 deny-delete-config 2233 ietf-netconf 2234 delete-config 2235 exec 2236 deny 2237 2238 Do not allow limited or guest group 2239 to delete any configurations. 2240 2241 2242 2244 2245 limited-acl 2246 limited 2248 2249 permit-edit-config 2250 ietf-netconf 2251 edit-config 2252 exec 2253 permit 2254 2255 Allow the limited group to edit the configuration. 2256 2257 2258 2260 2262 This example shows three protocol operation rules: 2264 deny-kill-session: This rule prevents the "limited" or "guest" 2265 groups from invoking the NETCONF protocol 2266 operation. 2268 deny-delete-config: This rule prevents the "limited" or "guest" 2269 groups from invoking the NETCONF protocol 2270 operation. 2272 permit-edit-config: This rule allows the "limited" group to invoke 2273 the NETCONF protocol operation. This rule will have 2274 no real effect unless the "exec-default" leaf is set to "deny". 2276 B.4. Data Node Rule Example 2278 Data node rules are used to control access to specific (config and 2279 non-config) data nodes within the NETCONF content provided by the 2280 server. 2282 2283 2284 guest-acl 2285 guest 2287 2288 deny-nacm 2289 2290 /n:nacm 2291 2292 * 2293 deny 2294 2295 Deny the guest group any access to the /nacm data. 2296 2297 2298 2300 2301 limited-acl 2302 limited 2304 2305 permit-acme-config 2306 2307 /acme:acme-netconf/acme:config-parameters 2308 2309 2310 read create update delete 2311 2312 permit 2313 2314 Allow the limited group complete access to the acme 2315 NETCONF configuration parameters. Showing long form 2316 of 'access-operations' instead of shorthand. 2317 2318 2319 2321 2322 guest-limited-acl 2323 guest 2324 limited 2326 2327 permit-dummy-interface 2328 2329 /acme:interfaces/acme:interface[acme:name='dummy'] 2330 2331 read update 2332 permit 2333 2334 Allow the limited and guest groups read 2335 and update access to the dummy interface. 2336 2337 2338 2340 2341 admin-acl 2342 admin 2343 2344 permit-interface 2345 2346 /acme:interfaces/acme:interface 2347 2348 * 2349 permit 2350 2351 Allow admin full access to all acme interfaces. 2352 2353 2354 2355 2357 This example shows four data node rules: 2359 deny-nacm: This rule denies the "guest" group any access to the 2360 subtree. Note that the default namespace is only 2361 applicable because this subtree is defined in the same namespace 2362 as the element. 2364 permit-acme-config: This rule gives the "limited" group read-write 2365 access to the acme . 2367 permit-dummy-interface: This rule gives the "limited" and "guest" 2368 groups read-update access to the acme entry named 2369 "dummy". This entry cannot be created or deleted by these groups, 2370 just altered. 2372 permit-interface: This rule gives the "admin" group read-write 2373 access to all acme entries. 2375 B.5. Notification Rule Example 2377 Notification rules are used to control access to a specific 2378 notification event type. 2380 2381 2382 sys-acl 2383 limited 2384 guest 2386 2387 deny-config-change 2388 acme-system 2389 sys-config-change 2390 read 2391 deny 2392 2393 Do not allow the guest or limited groups 2394 to receive config change events. 2395 2396 2397 2398 2400 This example shows one notification rule: 2402 deny-config-change: This rule prevents the "limited" or "guest" 2403 groups from receiving the acme event type. 2405 Authors' Addresses 2407 Andy Bierman 2408 YumaWorks 2409 685 Cochran St. 2410 Suite #160 2411 Simi Valley, CA 93065 2412 USA 2414 EMail: andy@yumaworks.com 2415 Martin Bjorklund 2416 Tail-f Systems 2418 EMail: mbj@tail-f.com