idnits 2.17.1 draft-ietf-netconf-rfc6536bis-04.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 28, 2017) is 2487 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 30, 2017 June 28, 2017 8 Network Configuration Protocol (NETCONF) Access Control Model 9 draft-ietf-netconf-rfc6536bis-04 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 30, 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. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 46 118 A.2. v02 to v03 . . . . . . . . . . . . . . . . . . . . . . . 46 119 A.3. v01 to v02 . . . . . . . . . . . . . . . . . . . . . . . 46 120 A.4. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 46 121 A.5. v00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 122 Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 46 123 B.1. Example . . . . . . . . . . . . . . . . . . . . 46 124 B.2. Module Rule Example . . . . . . . . . . . . . . . . . . . 47 125 B.3. Protocol Operation Rule Example . . . . . . . . . . . . . 49 126 B.4. Data Node Rule Example . . . . . . . . . . . . . . . . . 51 127 B.5. Notification Rule Example . . . . . . . . . . . . . . . . 53 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 130 1. Introduction 132 The NETCONF and RESTCONF protocols do not provide any standard 133 mechanisms to restrict the protocol operations and content that each 134 user is authorized to access. 136 There is a need for interoperable management of the controlled access 137 to administrator-selected portions of the available NETCONF or 138 RESTCONF content within a particular server. 140 This document addresses access control mechanisms for the Operations 141 and Content layers of NETCONF, as defined in [RFC6241], and RESTCONF, 142 as defined in [RFC8040]. It contains three main sections: 144 1. Access Control Design Objectives 145 2. NETCONF Access Control Model (NACM) 147 3. YANG Data Model (ietf-netconf-acm.yang) 149 YANG version 1.1 [RFC7950] adds two new constructs that need special 150 access control handling. The "action" statement is similar to the 151 "rpc" statement, except it is located within a data node. The 152 "notification" statement can also be located within a data node. 154 1.1. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 The following terms are defined in 161 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 163 o datastore 165 o configuration datastore 167 o conventional configuration datastore 169 o candidate configuration datastore 171 o running configuration datastore 173 o startup configuration datastore 175 o operational state datastore 177 o client 179 o server 181 The following terms are defined in [RFC6241] and are not redefined 182 here: 184 o protocol operation 186 o session 188 o user 190 The following terms are defined in [RFC7950] and are not redefined 191 here: 193 o action 195 o data node 197 o data definition statement 199 The following terms are defined in [RFC8040] and are not redefined 200 here: 202 o data resource 204 o datastore resource 206 o operation resource 208 o target resource 210 The following term is defined in [RFC7230] and is not redefined here: 212 o request URI 214 The following terms are used throughout this document: 216 access control: A security feature provided by the server that 217 allows an administrator to restrict access to a subset of all 218 protocol operations and data, based on various criteria. 220 access control model (ACM): A conceptual model used to configure and 221 monitor the access control procedures desired by the administrator 222 to enforce a particular access control policy. 224 access control rule: The criterion used to determine if a particular 225 protocol operation will be permitted or denied. 227 access operation: How a request attempts to access a conceptual 228 object. One of "none", "read", "create", "delete", "update", or 229 "execute". 231 data node hierarchy: The hierarchy of data nodes that identifies the 232 specific "action" or "notification" node in the datastore. 234 recovery session: A special administrative session that is given 235 unlimited NETCONF access and is exempt from all access control 236 enforcement. The mechanism(s) used by a server to control and 237 identify whether or not a session is a recovery session are 238 implementation specific and outside the scope of this document. 240 write access: A shorthand for the "create", "delete", and "update" 241 access operations. 243 1.2. Changes Since RFC 6536 245 The NACM procedures and data model have been updated to support new 246 data modeling capabilities in the version 1.1. of the YANG data 247 modeling language. The "action" and "notification" statements can be 248 used within data nodes to define data-model specific operations and 249 notifications. 251 An important use-case for these new YANG statements is the increased 252 access control granularity that can be achieved over top-level "rpc" 253 and "notification" statements. The new "action" and "notification" 254 statements are used within data nodes, and access to the action or 255 notification can be restricted to specific instances of these data 256 nodes. 258 Support for the RESTCONF protocol has been added. The RESTCONF 259 operations are similar to the NETCONF operations, so a simple mapping 260 to the existing NACM procedures and data model is possible. 262 2. Access Control Design Objectives 264 This section documents the design objectives for the NETCONF Access 265 Control Model presented in Section 3. 267 2.1. Access Control Points 269 NETCONF allows new protocol operations to be added at any time, and 270 the YANG Data Modeling Language supports this feature. It is not 271 possible to design an ACM for NETCONF that only focuses on a static 272 set of protocol operations, like some other protocols. Since few 273 assumptions can be made about an arbitrary protocol operation, the 274 NETCONF architectural server components need to be protected at three 275 conceptual control points. 277 These access control points, described in Figure 1, are as follows: 279 protocol operation: Permission to invoke specific protocol 280 operations. 282 datastore: Permission to read and/or alter specific data nodes 283 within any datastore. 285 notification: Permission to receive specific notification event 286 types. 288 +-------------+ +-------------+ 289 client | protocol | | data node | 290 request --> | operation | -------------> | access | 291 | allowed? | datastore | allowed? | 292 +-------------+ or state +-------------+ 293 data access 295 +----------------+ 296 | notification | 297 event --> | allowed? | 298 +----------------+ 300 Figure 1 302 2.2. Simplicity 304 There is concern that a complicated ACM will not be widely deployed 305 because it is too hard to use. It needs to be easy to do simple 306 things and possible to do complex things, instead of hard to do 307 everything. 309 Configuration of the access control system needs to be as simple as 310 possible. Simple and common tasks need to be easy to configure and 311 require little expertise or domain-specific knowledge. Complex tasks 312 are possible using additional mechanisms, which may require 313 additional expertise. 315 A single set of access control rules ought to be able to control all 316 types of NETCONF protocol operation invocation, all datastore access, 317 and all notification events. 319 Access control ought to be defined with a small and familiar set of 320 permissions, while still allowing full control of datastore access. 322 2.3. Procedural Interface 324 The NETCONF protocol uses a remote procedure call model and an 325 extensible set of protocol operations. Access control for any 326 possible protocol operation is necessary. 328 2.4. Datastore Access 330 It is necessary to control access to specific nodes and subtrees 331 within the datastore, regardless of which protocol operation, 332 standard or proprietary, was used to access the datastore. 334 2.5. Users and Groups 336 It is necessary that access control rules for a single user or a 337 configurable group of users can be configured. 339 The ACM needs to support the concept of administrative groups, to 340 support the well-established distinction between a root account and 341 other types of less-privileged conceptual user accounts. These 342 groups need to be configurable by the administrator. 344 It is necessary that the user-to-group mapping can be delegated to a 345 central server, such as a RADIUS server [RFC2865][RFC5607]. Since 346 authentication is performed by the NETCONF transport layer and RADIUS 347 performs authentication and service authorization at the same time, 348 the underlying NETCONF transport needs to be able to report a set of 349 group names associated with the user to the server. It is necessary 350 that the administrator can disable the usage of these group names 351 within the ACM. 353 2.6. Maintenance 355 It ought to be possible to disable part or all of the access control 356 model enforcement procedures without deleting any access control 357 rules. 359 2.7. Configuration Capabilities 361 Suitable configuration and monitoring mechanisms are needed to allow 362 an administrator to easily manage all aspects of the ACM's behavior. 363 A standard data model, suitable for use with the 364 protocol operation, needs to be available for this purpose. 366 Access control rules to restrict access operations on specific 367 subtrees within the configuration datastore need to be supported. 369 2.8. Identifying Security-Sensitive Content 371 One of the most important aspects of the data model documentation, 372 and biggest concerns during deployment, is the identification of 373 security-sensitive content. This applies to protocol operations in 374 NETCONF, not just data and notifications. 376 It is mandatory for security-sensitive objects to be documented in 377 the Security Considerations section of an RFC. This is nice, but it 378 is not good enough, for the following reasons: 380 o This documentation-only approach forces administrators to study 381 the RFC and determine if there are any potential security risks 382 introduced by a new data model. 384 o If any security risks are identified, then the administrator must 385 study some more RFC text and determine how to mitigate the 386 security risk(s). 388 o The ACM on each server must be configured to mitigate the security 389 risks, e.g., require privileged access to read or write the 390 specific data identified in the Security Considerations section. 392 o If the ACM is not pre-configured, then there will be a time window 393 of vulnerability after the new data model is loaded and before the 394 new access control rules for that data model are configured, 395 enabled, and debugged. 397 Often, the administrator just wants to disable default access to the 398 secure content, so no inadvertent or malicious changes can be made to 399 the server. This allows the default rules to be more lenient, 400 without significantly increasing the security risk. 402 A data model designer needs to be able to use machine-readable 403 statements to identify content that needs to be protected by default. 404 This will allow client and server tools to automatically identify 405 data-model-specific security risks, by denying access to sensitive 406 data unless the user is explicitly authorized to perform the 407 requested access operation. 409 3. NETCONF Access Control Model (NACM) 411 3.1. Introduction 413 This section provides a high-level overview of the access control 414 model structure. It describes the NETCONF protocol message 415 processing model and the conceptual access control requirements 416 within that model. 418 3.1.1. Features 420 The NACM data model provides the following features: 422 o Independent control of remote procedure call (RPC), action, data, 423 and notification access. 425 o Simple access control rules configuration data model that is easy 426 to use. 428 o The concept of an emergency recovery session is supported, but 429 configuration of the server for this purpose is beyond the scope 430 of this document. An emergency recovery session will bypass all 431 access control enforcement, in order to allow it to initialize or 432 repair the NACM configuration. 434 o A simple and familiar set of datastore permissions is used. 436 o Support for YANG security tagging (e.g., "nacm:default-deny-write" 437 statement) allows default security modes to automatically exclude 438 sensitive data. 440 o Separate default access modes for read, write, and execute 441 permissions. 443 o Access control rules are applied to configurable groups of users. 445 o The access control enforcement procedures can be disabled during 446 operation, without deleting any access control rules, in order to 447 debug operational problems. 449 o Access control rules are simple to configure. 451 o The number of denied protocol operation requests and denied 452 datastore write requests can be monitored by the client. 454 o Simple unconstrained YANG instance identifiers are used to 455 configure access control rules for specific data nodes. 457 3.1.2. External Dependencies 459 The NETCONF protocol [RFC6241] is used for network management 460 purposes within this document. 462 The RESTCONF protocol [RFC8040] is used for network management 463 purposes within this document. 465 The YANG Data Modeling Language [RFC7950] is used to define the data 466 models for use with the NETCONF or RESTCONF protocols. YANG is also 467 used to define the data model in this document. 469 3.1.3. Message Processing Model 471 The following diagram shows the conceptual message flow model, 472 including the points at which access control is applied during 473 NETCONF message processing. 475 RESTCONF operations are mapped to the access control model based on 476 the HTTP method and resource class used in the operation. For 477 example, a POST method on a data resource is considered "write data 478 node" access, but a POST method on an operation resource is 479 considered "operation" access. 481 +-------------------------+ 482 | session | 483 | (username) | 484 +-------------------------+ 485 | ^ 486 V | 487 +--------------+ +---------------+ 488 | message | | message | 489 | dispatcher | | generator | 490 +--------------+ +---------------+ 491 | | ^ ^ 492 | V | | 493 | +=============+ | | 494 | | pre-read | | | 495 | | data node | | | 496 | | acc. ctl | | | 497 | +=============+ | | 498 | | | | 499 V V | | 500 +===========+ +-------------+ +----------------+ 501 | operation |---> | reply | | | 502 | acc. ctl | | generator | | generator | 503 +===========+ +-------------+ +----------------+ 504 | ^ ^ ^ 505 V +------+ | | 506 +-----------+ | +=============+ +================+ 507 | operation | | | read | | | 508 | processor |-+ | data node | | access ctl | 509 | | | acc. ctl | | | 510 +-----------+ +=============+ +================+ 511 | | ^ ^ ^ 512 V +----------------+ | | | 513 +===========+ | | | +============+ 514 | write | | | | | pre-read | 515 | data node | | | | | data node | 516 | acc. ctl | -----------+ | | | | acc. ctl | 517 +===========+ | | | | +============+ 518 | | | | | ^ 519 V V V | | | 520 +---------------+ +-------------------+ 521 | configuration | ---> | server | 522 | datastore | | instrumentation | 523 | | <--- | | 524 +---------------+ +-------------------+ 526 Figure 2 528 The following high-level sequence of conceptual processing steps is 529 executed for each received message, if access control 530 enforcement is enabled: 532 o For each active session, access control is applied individually to 533 all messages (except ) received by the 534 server, unless the session is identified as a recovery session. 536 o If the operation defined in [RFC7950] is invoked, then 537 read access is required for all instances in the hierarchy of data 538 nodes that identifies the specific action in the datastore, and 539 execute access is required for the action node. If the user is 540 not authorized to read all the specified data nodes and execute 541 the action, then the request is rejected with an "access-denied" 542 error. 544 o Otherwise, if the user is not authorized to execute the specified 545 protocol operation, then the request is rejected with an "access- 546 denied" error. 548 o If a datastore is accessed by the protocol operation, then the 549 server checks if the client is authorized to access the nodes in 550 the datastore. If the user is not authorized to perform the 551 requested access operation on the requested data, then the request 552 is rejected with an "access-denied" error. 554 The following sequence of conceptual processing steps is executed for 555 each generated notification event, if access control enforcement is 556 enabled: 558 o Server instrumentation generates a notification for a particular 559 subscription. 561 o If the notification statement is specified within a data subtree, 562 as specified in [RFC7950], then read access is required for all 563 instances in the hierarchy of data nodes that identifies the 564 specific notification in the datastore, and read access is 565 required for the notification node. If the user is not authorized 566 to read all the specified data nodes and the notification node, 567 then the notification is dropped for that subscription. 569 o If the notification statement is a top-level statement, the 570 notification access control enforcer checks the notification event 571 type, and if it is one that the user is not authorized to read, 572 then the notification is dropped for that subscription. 574 3.2. Datastore Access 576 The same access control rules apply to all datastores that support 577 NACM, for example, the candidate configuration datastore or the 578 running configuration datastore. 580 All conventional configuration datastores and the operational state 581 datastore are controlled by NACM. Local or remote files or 582 datastores accessed via the parameter are not controlled by 583 NACM. 585 3.2.1. Mapping New Datastores to NACM 587 It is possible that new datastores will be defined over time for use 588 with the NETCONF protocol. NACM MAY be applied to other datastores 589 that have similar access rights as defined in NACM. To apply NACM to 590 a new datastore, the new datastore specification needs to define how 591 it maps to the NACM CRUDX access rights. It is possible only a 592 subset of the NACM access rights would be applicable. For example, 593 only retrieval access control would be needed for a read-only 594 datastore. Operations and access rights not supported by the NACM 595 CRUDX model are outside the scope of this document. A datastore does 596 not need to use NACM, e.g., the datastore specification defines 597 something else, or does not use access control. 599 3.2.2. Access Rights 601 A small set of hard-wired datastore access rights is needed to 602 control access to all possible NETCONF protocol operations, including 603 vendor extensions to the standard protocol operation set. 605 The "CRUDX" model can support all NETCONF protocol operations: 607 o Create: allows the client to add a new data node instance to a 608 datastore. 610 o Read: allows the client to read a data node instance from a 611 datastore or receive the notification event type. 613 o Update: allows the client to update an existing data node instance 614 in a datastore. 616 o Delete: allows the client to delete a data node instance from a 617 datastore. 619 o eXec: allows the client to execute the operation. 621 3.2.3. RESTCONF Methods 623 The RESTCONF protocol utilizes HTTP methods to perform datastore 624 operations, similar to the NETCONF protocol. The NACM procedures 625 were originally written for NETCONF protocol operations so the 626 RESTCONF methods are mapped to NETCONF operations for the purpose of 627 access control processing. The enforcement procedures described 628 within this document apply to both protocols unless explicitly stated 629 otherwise. 631 The request URI needs to be considered when processing RESTCONF 632 requests on data resources: 634 o For HEAD and GET requests, any data nodes which are ancestor nodes 635 of the target resource are considered to be part of the retrieval 636 request for access control purposes. 638 o For PUT, PATCH, and DELETE requests, any data nodes which are 639 ancestor nodes of the target resource are not considered to be 640 part of the edit request for access control purposes. The edit 641 operation for these nodes is considered to be 'none'. The edit 642 begins at the target resource. 644 o For POST requests on data resources, any data nodes which are 645 specified in the request URI, including the target resource, are 646 not considered to be part of the edit request for access control 647 purposes. The edit operation for these nodes is considered to be 648 'none'. The edit begins at a child node of the target resource, 649 specified in the message body. 651 Not all RESTCONF methods are subject to access control. The 652 following table specifies how each method is mapped to NETCONF 653 protocol operations. The value 'none' indicates that NACM is not 654 applied at all to the specific RESTCONF method. 656 +---------+-----------------+---------------------+-----------------+ 657 | method | resource class | NETCONF operation | Edit operation | 658 +---------+-----------------+---------------------+-----------------+ 659 | OPTIONS | all | none | N/A | 660 | HEAD | all | | N/A | 661 | GET | all | | N/A | 662 | POST | datastore, data | | create | 663 | POST | operation | specified operation | N/A | 664 | PUT | data | | create, replace | 665 | PUT | datastore | | replace | 666 | PATCH | data, datastore | | merge | 667 | DELETE | data | | delete | 668 +---------+-----------------+---------------------+-----------------+ 670 Table 1: Mapping RESTCONF Methods to NETCONF 672 3.2.4. and Operations 674 Data nodes to which the client does not have read access are silently 675 omitted from the message. This is done to allow NETCONF 676 filters for and to function properly, instead of 677 causing an "access-denied" error because the filter criteria would 678 otherwise include unauthorized read access to some data nodes. For 679 NETCONF filtering purposes, the selection criteria is applied to the 680 subset of nodes that the user is authorized to read, not the entire 681 datastore. 683 3.2.5. Operation 685 The NACM access rights are not directly coupled to the 686 "operation" attribute, although they are similar. Instead, a NACM 687 access right applies to all protocol operations that would result in 688 a particular access operation to the target datastore. This section 689 describes how these access rights apply to the specific access 690 operations supported by the protocol operation. 692 If the effective access operation is "none" (i.e., default- 693 operation="none") for a particular data node, then no access control 694 is applied to that data node. This is required to allow access to a 695 subtree within a larger data structure. For example, a user may be 696 authorized to create a new "/interfaces/interface" list entry but not 697 be authorized to create or delete its parent container 698 ("/interfaces"). If the "/interfaces" container already exists in 699 the target datastore, then the effective operation will be "none" for 700 the "/interfaces" node if an "/interfaces/interface" list entry is 701 edited. 703 If the protocol operation would result in the creation of a datastore 704 node and the user does not have "create" access permission for that 705 node, the protocol operation is rejected with an "access-denied" 706 error. 708 If the protocol operation would result in the deletion of a datastore 709 node and the user does not have "delete" access permission for that 710 node, the protocol operation is rejected with an "access-denied" 711 error. 713 If the protocol operation would result in the modification of a 714 datastore node and the user does not have "update" access permission 715 for that node, the protocol operation is rejected with an "access- 716 denied" error. 718 A "merge" or "replace" operation may include data nodes 719 that do not alter portions of the existing datastore. For example, a 720 container or list node may be present for naming purposes but does 721 not actually alter the corresponding datastore node. These unaltered 722 data nodes are ignored by the server and do not require any access 723 rights by the client. 725 A "merge" operation may include data nodes but not 726 include particular child data nodes that are present in the 727 datastore. These missing data nodes within the scope of a "merge" 728 operation are ignored by the server and do not require 729 any access rights by the client. 731 The contents of specific restricted datastore nodes MUST NOT be 732 exposed in any elements within the reply. 734 3.2.6. Operation 736 Access control for the protocol operation requires 737 special consideration because the administrator may be replacing the 738 entire target datastore. 740 If the source of the protocol operation is the running 741 configuration datastore and the target is the startup configuration 742 datastore, the client is only required to have permission to execute 743 the protocol operation. 745 Otherwise: 747 o If the source of the operation is a datastore, then 748 data nodes to which the client does not have read access are 749 silently omitted. 751 o If the target of the operation is a datastore, the 752 client needs access to the modified nodes, specifically: 754 * If the protocol operation would result in the creation of a 755 datastore node and the user does not have "create" access 756 permission for that node, the protocol operation is rejected 757 with an "access-denied" error. 759 * If the protocol operation would result in the deletion of a 760 datastore node and the user does not have "delete" access 761 permission for that node, the protocol operation is rejected 762 with an "access-denied" error. 764 * If the protocol operation would result in the modification of a 765 datastore node and the user does not have "update" access 766 permission for that node, the protocol operation is rejected 767 with an "access-denied" error. 769 3.2.7. Operation 771 Access to the protocol operation is denied by 772 default. The "exec-default" leaf does not apply to this protocol 773 operation. Access control rules must be explicitly configured to 774 allow invocation by a non-recovery session. 776 3.2.8. Operation 778 The server MUST determine the exact nodes in the running 779 configuration datastore that are actually different and only check 780 "create", "update", and "delete" access permissions for this set of 781 nodes, which could be empty. 783 For example, if a session can read the entire datastore but only 784 change one leaf, that session needs to be able to edit and commit 785 that one leaf. 787 3.2.9. Operation 789 The client is only required to have permission to execute the 790 protocol operation. No datastore permissions are 791 needed. 793 3.2.10. Operation 795 The operation does not directly alter a datastore. 796 However, it allows one session to disrupt another session that is 797 editing a datastore. 799 Access to the protocol operation is denied by default. 800 The "exec-default" leaf does not apply to this protocol operation. 801 Access control rules must be explicitly configured to allow 802 invocation by a non-recovery session. 804 3.3. Model Components 806 This section defines the conceptual components related to the access 807 control model. 809 3.3.1. Users 811 A "user" is the conceptual entity that is associated with the access 812 permissions granted to a particular session. A user is identified by 813 a string that is unique within the server. 815 As described in [RFC6241], the username string is derived from the 816 transport layer during session establishment. If the transport layer 817 cannot authenticate the user, the session is terminated. 819 3.3.2. Groups 821 Access to a specific NETCONF protocol operation is granted to a 822 session, associated with a group, not a user. 824 A group is identified by its name. All group names are unique within 825 the server. 827 A group member is identified by a username string. 829 The same user can be a member of multiple groups. 831 3.3.3. Emergency Recovery Session 833 The server MAY support a recovery session mechanism, which will 834 bypass all access control enforcement. This is useful for 835 restricting initial access and repairing a broken access control 836 configuration. 838 3.3.4. Global Enforcement Controls 840 There are five global controls that are used to help control how 841 access control is enforced. 843 3.3.4.1. enable-nacm Switch 845 A global "enable-nacm" on/off switch is provided to enable or disable 846 all access control enforcement. When this global switch is set to 847 "true", then all requests are checked against the access control 848 rules and only permitted if configured to allow the specific access 849 request. When this global switch is set to "false", then all access 850 requested are permitted. 852 3.3.4.2. read-default Switch 854 An on/off "read-default" switch is provided to enable or disable 855 default access to receive data in replies and notifications. When 856 the "enable-nacm" global switch is set to "true", then this global 857 switch is relevant if no matching access control rule is found to 858 explicitly permit or deny read access to the requested datastore data 859 or notification event type. 861 When this global switch is set to "permit" and no matching access 862 control rule is found for the datastore read or notification event 863 requested, then access is permitted. 865 When this global switch is set to "deny" and no matching access 866 control rule is found for the datastore read or notification event 867 requested, then access is denied. 869 3.3.4.3. write-default Switch 871 An on/off "write-default" switch is provided to enable or disable 872 default access to alter configuration data. When the "enable-nacm" 873 global switch is set to "true", then this global switch is relevant 874 if no matching access control rule is found to explicitly permit or 875 deny write access to the requested datastore data. 877 When this global switch is set to "permit" and no matching access 878 control rule is found for the datastore write requested, then access 879 is permitted. 881 When this global switch is set to "deny" and no matching access 882 control rule is found for the datastore write requested, then access 883 is denied. 885 3.3.4.4. exec-default Switch 887 An on/off "exec-default" switch is provided to enable or disable 888 default access to execute protocol operations. When the "enable- 889 nacm" global switch is set to "true", then this global switch is 890 relevant if no matching access control rule is found to explicitly 891 permit or deny access to the requested NETCONF protocol operation. 893 When this global switch is set to "permit" and no matching access 894 control rule is found for the NETCONF protocol operation requested, 895 then access is permitted. 897 When this global switch is set to "deny" and no matching access 898 control rule is found for the NETCONF protocol operation requested, 899 then access is denied. 901 3.3.4.5. enable-external-groups Switch 903 When this global switch is set to "true", the group names reported by 904 the NETCONF transport layer for a session are used together with the 905 locally configured group names to determine the access control rules 906 for the session. 908 When this switch is set to "false", the group names reported by the 909 NETCONF transport layer are ignored by NACM. 911 3.3.5. Access Control Rules 913 There are four types of rules available in NACM: 915 module rule: controls access for definitions in a specific YANG 916 module, identified by its name. 918 protocol operation rule: controls access for a specific protocol 919 operation, identified by its YANG module and name. 921 data node rule: controls access for a specific data node, identified 922 by its path location within the conceptual XML document for the 923 data node. 925 notification rule: controls access for a specific notification event 926 type, identified by its YANG module and name. 928 3.4. Access Control Enforcement Procedures 930 There are seven separate phases that need to be addressed, four of 931 which are related to the NETCONF message processing model 932 (Section 3.1.3). In addition, the initial startup mode for a NETCONF 933 server, session establishment, and "access-denied" error-handling 934 procedures also need to be considered. 936 The server MUST use the access control rules in effect at the time it 937 starts processing the message. The same access control rules MUST 938 stay in effect for the processing of the entire message. 940 3.4.1. Initial Operation 942 Upon the very first startup of the NETCONF server, the access control 943 configuration will probably not be present. If it isn't, a server 944 MUST NOT allow any write access to any session role except a recovery 945 session. 947 Access rules are enforced any time a request is initiated from a user 948 session. Access control is not enforced for server-initiated access 949 requests, such as the initial load of the running configuration 950 datastore, during bootup. 952 3.4.2. Session Establishment 954 The access control model applies specifically to the well-formed XML 955 content transferred between a client and a server after session 956 establishment has been completed and after the exchange has 957 been successfully completed. 959 Once session establishment is completed and a user has been 960 authenticated, the NETCONF transport layer reports the username and a 961 possibly empty set of group names associated with the user to the 962 NETCONF server. The NETCONF server will enforce the access control 963 rules, based on the supplied username, group names, and the 964 configuration data stored on the server. 966 3.4.3. "access-denied" Error Handling 968 The "access-denied" error-tag is generated when the access control 969 system denies access to either a request to invoke a protocol 970 operation or a request to perform a particular access operation on 971 the configuration datastore. 973 A server MUST NOT include any information the client is not allowed 974 to read in any elements within the response. 976 3.4.4. Incoming RPC Message Validation 978 The diagram below shows the basic conceptual structure of the access 979 control processing model for incoming NETCONF messages within a 980 server. 982 NETCONF server 983 +------------+ 984 | XML | 985 | message | 986 | dispatcher | 987 +------------+ 988 | 989 | 990 V 991 +------------+ 992 | NC-base NS | 993 | | 994 +------------+ 995 | | | 996 | | +-------------------------+ 997 | +------------+ | 998 V V V 999 +-----------+ +---------------+ +------------+ 1000 | Vendor NS | | NC-base NS | | NC-base NS | 1001 | | | | | | 1002 +-----------+ +---------------+ +------------+ 1003 | | 1004 | | 1005 V V 1006 +----------------------+ 1007 | | 1008 | configuration | 1009 | datastore | 1010 +----------------------+ 1012 Figure 3 1014 Access control begins with the message dispatcher. 1016 After the server validates the element and determines the 1017 namespace URI and the element name of the protocol operation being 1018 requested, the server verifies that the user is authorized to invoke 1019 the protocol operation. 1021 The server MUST separately authorize every protocol operation by 1022 following these steps: 1024 1. If the "enable-nacm" leaf is set to "false", then the protocol 1025 operation is permitted. 1027 2. If the requesting session is identified as a recovery session, 1028 then the protocol operation is permitted. 1030 3. If the requested operation is the NETCONF 1031 protocol operation, then the protocol operation is permitted. 1033 4. Check all the "group" entries for ones that contain a "user- 1034 name" entry that equals the username for the session making the 1035 request. If the "enable-external-groups" leaf is "true", add to 1036 these groups the set of groups provided by the transport layer. 1038 5. If no groups are found, continue with step 10. 1040 6. Process all rule-list entries, in the order they appear in the 1041 configuration. If a rule-list's "group" leaf-list does not 1042 match any of the user's groups, proceed to the next rule-list 1043 entry. 1045 7. For each rule-list entry found, process all rules, in order, 1046 until a rule that matches the requested access operation is 1047 found. A rule matches if all of the following criteria are met: 1049 * The rule's "module-name" leaf is "*" or equals the name of 1050 the YANG module where the protocol operation is defined. 1052 * The rule does not have a "rule-type" defined or the "rule- 1053 type" is "protocol-operation" and the "rpc-name" is "*" or 1054 equals the name of the requested protocol operation. 1056 * The rule's "access-operations" leaf has the "exec" bit set or 1057 has the special value "*". 1059 8. If a matching rule is found, then the "action" leaf is checked. 1060 If it is equal to "permit", then the protocol operation is 1061 permitted; otherwise, it is denied. 1063 9. At this point, no matching rule was found in any rule-list 1064 entry. 1066 10. If the requested protocol operation is defined in a YANG module 1067 advertised in the server capabilities and the "rpc" statement 1068 contains a "nacm:default-deny-all" statement, then the protocol 1069 operation is denied. 1071 11. If the requested protocol operation is the NETCONF or , then the protocol operation is 1073 denied. 1075 12. If the "exec-default" leaf is set to "permit", then permit the 1076 protocol operation; otherwise, deny the request. 1078 If the user is not authorized to invoke the protocol operation, then 1079 an is generated with the following information: 1081 error-tag: access-denied 1083 error-path: Identifies the requested protocol operation. The 1084 following example represents the protocol operation 1085 in the NETCONF base namespace: 1087 1089 /nc:rpc/nc:edit-config 1090 1092 If a datastore is accessed, either directly or as a side effect of 1093 the protocol operation, then the server MUST intercept the access 1094 operation and make sure the user is authorized to perform the 1095 requested access operation on the specified data, as defined in 1096 Section 3.4.5. 1098 3.4.5. Data Node Access Validation 1100 If a data node within a datastore is accessed, or an action or 1101 notification tied to a data node, then the server MUST ensure that 1102 the user is authorized to perform the requested "read", "create", 1103 "update", "delete", or "execute" access operation on the specified 1104 data node. 1106 If an action is requested to be executed, the server MUST ensure that 1107 the user is authorized to perform the "execute" access operation on 1108 the requested action. 1110 If a notification tied to a data node is generated, the server MUST 1111 ensure that the user is authorized to perform the "read" access 1112 operation on the requested notification. 1114 The data node access request is authorized by following these steps: 1116 1. If the "enable-nacm" leaf is set to "false", then the access 1117 operation is permitted. 1119 2. If the requesting session is identified as a recovery session, 1120 then the access operation is permitted. 1122 3. Check all the "group" entries for ones that contain a "user- 1123 name" entry that equals the username for the session making the 1124 request. If the "enable-external-groups" leaf is "true", add to 1125 these groups the set of groups provided by the transport layer. 1127 4. If no groups are found, continue with step 9. 1129 5. Process all rule-list entries, in the order they appear in the 1130 configuration. If a rule-list's "group" leaf-list does not 1131 match any of the user's groups, proceed to the next rule-list 1132 entry. 1134 6. For each rule-list entry found, process all rules, in order, 1135 until a rule that matches the requested access operation is 1136 found. A rule matches if all of the following criteria are met: 1138 * The rule's "module-name" leaf is "*" or equals the name of 1139 the YANG module where the requested data node is defined. 1141 * The rule does not have a "rule-type" defined or the "rule- 1142 type" is "data-node" and the "path" matches the requested 1143 data node, action node, or notification node. 1145 * For a "read" access operation, the rule's "access-operations" 1146 leaf has the "read" bit set or has the special value "*". 1148 * For a "create" access operation, the rule's "access- 1149 operations" leaf has the "create" bit set or has the special 1150 value "*". 1152 * For a "delete" access operation, the rule's "access- 1153 operations" leaf has the "delete" bit set or has the special 1154 value "*". 1156 * For an "update" access operation, the rule's "access- 1157 operations" leaf has the "update" bit set or has the special 1158 value "*". 1160 * For an "execute" access operation, the rule's "access- 1161 operations" leaf has the "exec" bit set or has the special 1162 value "*". 1164 7. If a matching rule is found, then the "action" leaf is checked. 1165 If it is equal to "permit", then the data node access is 1166 permitted; otherwise, it is denied. For a "read" access 1167 operation, "denied" means that the requested data is not 1168 returned in the reply. 1170 8. At this point, no matching rule was found in any rule-list 1171 entry. 1173 9. For a "read" access operation, if the requested data node is 1174 defined in a YANG module advertised in the server capabilities 1175 and the data definition statement contains a "nacm:default-deny- 1176 all" statement, then the requested data node is not included in 1177 the reply. 1179 10. For a "write" access operation, if the requested data node is 1180 defined in a YANG module advertised in the server capabilities 1181 and the data definition statement contains a "nacm:default-deny- 1182 write" or a "nacm:default-deny-all" statement, then the data 1183 node access request is denied. 1185 11. For a "read" access operation, if the "read-default" leaf is set 1186 to "permit", then include the requested data node in the reply; 1187 otherwise, do not include the requested data node in the reply. 1189 12. For a "write" access operation, if the "write-default" leaf is 1190 set to "permit", then permit the data node access request; 1191 otherwise, deny the request. 1193 13. For an "execute" access operation, if the "exec-default" leaf is 1194 set to "permit", then permit the request; otherwise, deny the 1195 request. 1197 3.4.6. Outgoing Authorization 1199 Configuration of access control rules specifically for descendant 1200 nodes of the notification event type element are outside the scope of 1201 this document. If the user is authorized to receive the notification 1202 event type, then it is also authorized to receive any data it 1203 contains. 1205 If the notification is specified within a data subtree, as specified 1206 in [RFC7950], then read access to the notification is required. 1207 Processing continues as described in Section 3.4.5. 1209 The following figure shows the conceptual message processing model 1210 for outgoing messages. 1212 NETCONF server 1213 +------------+ 1214 | XML | 1215 | message | 1216 | generator | 1217 +------------+ 1218 ^ 1219 | 1220 +----------------+ 1221 | | 1222 | generator | 1223 +----------------+ 1224 ^ 1225 | 1226 +=================+ 1227 | | 1228 | access control | 1229 | | 1230 +=================+ 1231 ^ 1232 | 1233 +------------------------+ 1234 | server instrumentation | 1235 +------------------------+ 1236 | ^ 1237 V | 1238 +----------------------+ 1239 | configuration | 1240 | datastore | 1241 +----------------------+ 1243 Figure 4 1245 The generation of a notification for a specific subscription 1246 [RFC5277] is authorized by following these steps: 1248 1. If the "enable-nacm" leaf is set to "false", then the 1249 notification is permitted. 1251 2. If the session is identified as a recovery session, then the 1252 notification is permitted. 1254 3. If the notification is the NETCONF or 1255 event type [RFC5277], then the 1256 notification is permitted. 1258 4. Check all the "group" entries for ones that contain a "user- 1259 name" entry that equals the username for the session making the 1260 request. If the "enable-external-groups" leaf is "true", add to 1261 these groups the set of groups provided by the transport layer. 1263 5. If no groups are found, continue with step 10. 1265 6. Process all rule-list entries, in the order they appear in the 1266 configuration. If a rule-list's "group" leaf-list does not 1267 match any of the user's groups, proceed to the next rule-list 1268 entry. 1270 7. For each rule-list entry found, process all rules, in order, 1271 until a rule that matches the requested access operation is 1272 found. A rule matches if all of the following criteria are met: 1274 * The rule's "module-name" leaf is "*" or equals the name of 1275 the YANG module where the notification is defined. 1277 * The rule does not have a "rule-type" defined or the "rule- 1278 type" is "notification" and the "notification-name" is "*" or 1279 equals the name of the notification. 1281 * The rule's "access-operations" leaf has the "read" bit set or 1282 has the special value "*". 1284 8. If a matching rule is found, then the "action" leaf is checked. 1285 If it is equal to "permit", then permit the notification; 1286 otherwise, drop the notification for the associated 1287 subscription. 1289 9. Otherwise, no matching rule was found in any rule-list entry. 1291 10. If the requested notification is defined in a YANG module 1292 advertised in the server capabilities and the "notification" 1293 statement contains a "nacm:default-deny-all" statement, then the 1294 notification is dropped for the associated subscription. 1296 11. If the "read-default" leaf is set to "permit", then permit the 1297 notification; otherwise, drop the notification for the 1298 associated subscription. 1300 3.5. Data Model Definitions 1301 3.5.1. Data Organization 1303 The following diagram highlights the contents and structure of the 1304 NACM YANG module. 1306 module: ietf-netconf-acm 1307 +--rw nacm 1308 +--rw enable-nacm? boolean 1309 +--rw read-default? action-type 1310 +--rw write-default? action-type 1311 +--rw exec-default? action-type 1312 +--rw enable-external-groups? boolean 1313 +--ro denied-operations yang:zero-based-counter32 1314 +--ro denied-data-writes yang:zero-based-counter32 1315 +--ro denied-notifications yang:zero-based-counter32 1316 +--rw groups 1317 | +--rw group* [name] 1318 | +--rw name group-name-type 1319 | +--rw user-name* user-name-type 1320 +--rw rule-list* [name] 1321 +--rw name string 1322 +--rw group* union 1323 +--rw rule* [name] 1324 +--rw name string 1325 +--rw module-name? union 1326 +--rw (rule-type)? 1327 | +--:(protocol-operation) 1328 | | +--rw rpc-name? union 1329 | +--:(notification) 1330 | | +--rw notification-name? union 1331 | +--:(data-node) 1332 | +--rw path node-instance-identifier 1333 +--rw access-operations? union 1334 +--rw action action-type 1335 +--rw comment? string 1337 3.5.2. YANG Module 1339 The following YANG module specifies the normative NETCONF content 1340 that MUST by supported by the server. 1342 The "ietf-netconf-acm" YANG module imports typedefs from [RFC6991]. 1344 file "ietf-netconf-acm@2017-06-28.yang" 1345 module ietf-netconf-acm { 1347 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm"; 1348 prefix "nacm"; 1350 import ietf-yang-types { 1351 prefix yang; 1352 } 1354 organization 1355 "IETF NETCONF (Network Configuration) Working Group"; 1357 contact 1358 "WG Web: 1359 WG List: 1361 Author: Andy Bierman 1362 1364 Author: Martin Bjorklund 1365 "; 1367 description 1368 "NETCONF Access Control Model. 1370 Copyright (c) 2012, 2017 IETF Trust and the persons 1371 identified as authors of the code. All rights reserved. 1373 Redistribution and use in source and binary forms, with or 1374 without modification, is permitted pursuant to, and subject 1375 to the license terms contained in, the Simplified BSD 1376 License set forth in Section 4.c of the IETF Trust's 1377 Legal Provisions Relating to IETF Documents 1378 (http://trustee.ietf.org/license-info). 1380 This version of this YANG module is part of RFC XXXX; see 1381 the RFC itself for full legal notices."; 1383 revision "2017-06-28" { 1384 description 1385 "Added support for YANG 1.1 actions and notifications tied to 1386 data nodes. Clarify how NACM extensions can be used by other 1387 data models."; 1388 reference 1389 "RFC XXXX: Network Configuration Protocol (NETCONF) 1390 Access Control Model"; 1391 } 1393 revision "2012-02-22" { 1394 description 1395 "Initial version"; 1396 reference 1397 "RFC 6536: Network Configuration Protocol (NETCONF) 1398 Access Control Model"; 1399 } 1401 /* 1402 * Extension statements 1403 */ 1405 extension default-deny-write { 1406 description 1407 "Used to indicate that the data model node 1408 represents a sensitive security system parameter. 1410 If present, the NETCONF server will only allow the designated 1411 'recovery session' to have write access to the node. An 1412 explicit access control rule is required for all other users. 1414 If the NACM module is used, then it must be enabled (i.e., 1415 /nacm/enable-nacm object equals 'true'), or this extension 1416 is ignored. 1418 The 'default-deny-write' extension MAY appear within a data 1419 definition statement. It is ignored otherwise."; 1420 } 1422 extension default-deny-all { 1423 description 1424 "Used to indicate that the data model node 1425 controls a very sensitive security system parameter. 1427 If present, the NETCONF server will only allow the designated 1428 'recovery session' to have read, write, or execute access to the 1429 node. An explicit access control rule is required for all other 1430 users. 1432 If the NACM module is used, then it must be enabled (i.e., 1433 /nacm/enable-nacm object equals 'true'), or this extension 1434 is ignored. 1436 The 'default-deny-all' extension MAY appear within a data 1437 definition statement, 'rpc' statement, or 'notification' 1438 statement. It is ignored otherwise."; 1439 } 1441 /* 1442 * Derived types 1443 */ 1445 typedef user-name-type { 1446 type string { 1447 length "1..max"; 1448 } 1449 description 1450 "General Purpose Username string."; 1451 } 1453 typedef matchall-string-type { 1454 type string { 1455 pattern '\*'; 1456 } 1457 description 1458 "The string containing a single asterisk '*' is used 1459 to conceptually represent all possible values 1460 for the particular leaf using this data type."; 1461 } 1463 typedef access-operations-type { 1464 type bits { 1465 bit create { 1466 description 1467 "Any protocol operation that creates a 1468 new data node."; 1469 } 1470 bit read { 1471 description 1472 "Any protocol operation or notification that 1473 returns the value of a data node."; 1474 } 1475 bit update { 1476 description 1477 "Any protocol operation that alters an existing 1478 data node."; 1479 } 1480 bit delete { 1481 description 1482 "Any protocol operation that removes a data node."; 1483 } 1484 bit exec { 1485 description 1486 "Execution access to the specified protocol operation."; 1487 } 1488 } 1489 description 1490 "Access Operation."; 1492 } 1494 typedef group-name-type { 1495 type string { 1496 length "1..max"; 1497 pattern '[^\*].*'; 1498 } 1499 description 1500 "Name of administrative group to which 1501 users can be assigned."; 1502 } 1504 typedef action-type { 1505 type enumeration { 1506 enum permit { 1507 description 1508 "Requested action is permitted."; 1509 } 1510 enum deny { 1511 description 1512 "Requested action is denied."; 1513 } 1514 } 1515 description 1516 "Action taken by the server when a particular 1517 rule matches."; 1518 } 1520 typedef node-instance-identifier { 1521 type yang:xpath1.0; 1522 description 1523 "Path expression used to represent a special 1524 data node, action, or notification instance identifier 1525 string. 1527 A node-instance-identifier value is an 1528 unrestricted YANG instance-identifier expression. 1529 All the same rules as an instance-identifier apply 1530 except predicates for keys are optional. If a key 1531 predicate is missing, then the node-instance-identifier 1532 represents all possible server instances for that key. 1534 This XPath expression is evaluated in the following context: 1536 o The set of namespace declarations are those in scope on 1537 the leaf element where this type is used. 1539 o The set of variable bindings contains one variable, 1540 'USER', which contains the name of the user of the current 1541 session. 1543 o The function library is the core function library, but 1544 note that due to the syntax restrictions of an 1545 instance-identifier, no functions are allowed. 1547 o The context node is the root node in the data tree. 1549 The accessible tree includes actions and notifications tied 1550 to data nodes."; 1551 } 1553 /* 1554 * Data definition statements 1555 */ 1557 container nacm { 1558 nacm:default-deny-all; 1560 description 1561 "Parameters for NETCONF Access Control Model."; 1563 leaf enable-nacm { 1564 type boolean; 1565 default true; 1566 description 1567 "Enables or disables all NETCONF access control 1568 enforcement. If 'true', then enforcement 1569 is enabled. If 'false', then enforcement 1570 is disabled."; 1571 } 1573 leaf read-default { 1574 type action-type; 1575 default "permit"; 1576 description 1577 "Controls whether read access is granted if 1578 no appropriate rule is found for a 1579 particular read request."; 1580 } 1582 leaf write-default { 1583 type action-type; 1584 default "deny"; 1585 description 1586 "Controls whether create, update, or delete access 1587 is granted if no appropriate rule is found for a 1588 particular write request."; 1589 } 1591 leaf exec-default { 1592 type action-type; 1593 default "permit"; 1594 description 1595 "Controls whether exec access is granted if no appropriate 1596 rule is found for a particular protocol operation request."; 1597 } 1599 leaf enable-external-groups { 1600 type boolean; 1601 default true; 1602 description 1603 "Controls whether the server uses the groups reported by the 1604 NETCONF transport layer when it assigns the user to a set of 1605 NACM groups. If this leaf has the value 'false', any group 1606 names reported by the transport layer are ignored by the 1607 server."; 1608 } 1610 leaf denied-operations { 1611 type yang:zero-based-counter32; 1612 config false; 1613 mandatory true; 1614 description 1615 "Number of times since the server last restarted that a 1616 protocol operation request was denied."; 1617 } 1619 leaf denied-data-writes { 1620 type yang:zero-based-counter32; 1621 config false; 1622 mandatory true; 1623 description 1624 "Number of times since the server last restarted that a 1625 protocol operation request to alter 1626 a configuration datastore was denied."; 1627 } 1629 leaf denied-notifications { 1630 type yang:zero-based-counter32; 1631 config false; 1632 mandatory true; 1633 description 1634 "Number of times since the server last restarted that 1635 a notification was dropped for a subscription because 1636 access to the event type was denied."; 1637 } 1639 container groups { 1640 description 1641 "NETCONF Access Control Groups."; 1643 list group { 1644 key name; 1646 description 1647 "One NACM Group Entry. This list will only contain 1648 configured entries, not any entries learned from 1649 any transport protocols."; 1651 leaf name { 1652 type group-name-type; 1653 description 1654 "Group name associated with this entry."; 1655 } 1657 leaf-list user-name { 1658 type user-name-type; 1659 description 1660 "Each entry identifies the username of 1661 a member of the group associated with 1662 this entry."; 1663 } 1664 } 1665 } 1667 list rule-list { 1668 key "name"; 1669 ordered-by user; 1670 description 1671 "An ordered collection of access control rules."; 1673 leaf name { 1674 type string { 1675 length "1..max"; 1676 } 1677 description 1678 "Arbitrary name assigned to the rule-list."; 1679 } 1680 leaf-list group { 1681 type union { 1682 type matchall-string-type; 1683 type group-name-type; 1685 } 1686 description 1687 "List of administrative groups that will be 1688 assigned the associated access rights 1689 defined by the 'rule' list. 1691 The string '*' indicates that all groups apply to the 1692 entry."; 1693 } 1695 list rule { 1696 key "name"; 1697 ordered-by user; 1698 description 1699 "One access control rule. 1701 Rules are processed in user-defined order until a match is 1702 found. A rule matches if 'module-name', 'rule-type', and 1703 'access-operations' match the request. If a rule 1704 matches, the 'action' leaf determines if access is granted 1705 or not."; 1707 leaf name { 1708 type string { 1709 length "1..max"; 1710 } 1711 description 1712 "Arbitrary name assigned to the rule."; 1713 } 1715 leaf module-name { 1716 type union { 1717 type matchall-string-type; 1718 type string; 1719 } 1720 default "*"; 1721 description 1722 "Name of the module associated with this rule. 1724 This leaf matches if it has the value '*' or if the 1725 object being accessed is defined in the module with the 1726 specified module name."; 1727 } 1728 choice rule-type { 1729 description 1730 "This choice matches if all leafs present in the rule 1731 match the request. If no leafs are present, the 1732 choice matches all requests."; 1734 case protocol-operation { 1735 leaf rpc-name { 1736 type union { 1737 type matchall-string-type; 1738 type string; 1739 } 1740 description 1741 "This leaf matches if it has the value '*' or if 1742 its value equals the requested protocol operation 1743 name."; 1744 } 1745 } 1746 case notification { 1747 leaf notification-name { 1748 type union { 1749 type matchall-string-type; 1750 type string; 1751 } 1752 description 1753 "This leaf matches if it has the value '*' or if its 1754 value equals the requested notification name."; 1755 } 1756 } 1757 case data-node { 1758 leaf path { 1759 type node-instance-identifier; 1760 mandatory true; 1761 description 1762 "Data Node Instance Identifier associated with the 1763 data node controlled by this rule. 1765 Configuration data or state data instance 1766 identifiers start with a top-level data node. A 1767 complete instance identifier is required for this 1768 type of path value. 1770 The special value '/' refers to all possible 1771 datastore contents."; 1772 } 1773 } 1774 } 1776 leaf access-operations { 1777 type union { 1778 type matchall-string-type; 1779 type access-operations-type; 1780 } 1781 default "*"; 1782 description 1783 "Access operations associated with this rule. 1785 This leaf matches if it has the value '*' or if the 1786 bit corresponding to the requested operation is set."; 1787 } 1789 leaf action { 1790 type action-type; 1791 mandatory true; 1792 description 1793 "The access control action associated with the 1794 rule. If a rule is determined to match a 1795 particular request, then this object is used 1796 to determine whether to permit or deny the 1797 request."; 1798 } 1800 leaf comment { 1801 type string; 1802 description 1803 "A textual description of the access rule."; 1804 } 1805 } 1806 } 1807 } 1808 } 1810 1812 Figure 5 1814 3.6. IANA Considerations 1816 This document reuses the URI for "ietf-netconf-acm" in "The IETF XML 1817 Registry". 1819 This document updates the module registration in the "YANG Module 1820 Names" registry to reference this RFC instead of RFC 6536. Following 1821 the format in [RFC6020], the following has been registered. 1823 Name: ietf-netconf-acm 1824 Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm 1825 Prefix: nacm 1826 reference: RFC XXXX 1828 3.7. Security Considerations 1830 This entire document discusses access control requirements and 1831 mechanisms for restricting NETCONF protocol behavior within a given 1832 session. 1834 This section highlights the issues for an administrator to consider 1835 when configuring a NETCONF server with NACM. 1837 3.7.1. NACM Configuration and Monitoring Considerations 1839 Configuration of the access control system is highly sensitive to 1840 system security. A server may choose not to allow any user 1841 configuration to some portions of it, such as the global security 1842 level or the groups that allowed access to system resources. 1844 By default, NACM enforcement is enabled. By default, "read" access 1845 to all datastore contents is enabled (unless "nacm:default-deny-all" 1846 is specified for the data definition), and "exec" access is enabled 1847 for safe protocol operations. An administrator needs to ensure that 1848 NACM is enabled and also decide if the default access parameters are 1849 set appropriately. Make sure the following data nodes are properly 1850 configured: 1852 o /nacm/enable-nacm (default "true") 1854 o /nacm/read-default (default "permit") 1856 o /nacm/write-default (default "deny") 1858 o /nacm/exec-default (default "permit") 1860 An administrator needs to restrict write access to all configurable 1861 objects within this data model. 1863 If write access is allowed for configuration of access control rules, 1864 then care needs to be taken not to disrupt the access control 1865 enforcement. For example, if the NACM access control rules are 1866 edited directly within the running configuration datastore (i.e., 1867 :writable-running capability is supported and used), then care needs 1868 to be taken not to allow unintended access while the edits are being 1869 done. 1871 An administrator needs to make sure that the translation from a 1872 transport- or implementation-dependent user identity to a NACM 1873 username is unique and correct. This requirement is specified in 1874 detail in Section 2.2 of [RFC6241]. 1876 An administrator needs to be aware that the YANG data structures 1877 representing access control rules (/nacm/rule-list and /nacm/rule- 1878 list/rule) are ordered by the client. The server will evaluate the 1879 access control rules according to their relative conceptual order 1880 within the running configuration datastore. 1882 Note that the /nacm/groups data structure contains the administrative 1883 group names used by the server. These group names may be configured 1884 locally and/or provided through an external protocol, such as RADIUS 1885 [RFC2865][RFC5607]. 1887 An administrator needs to be aware of the security properties of any 1888 external protocol used by the NETCONF transport layer to determine 1889 group names. For example, if this protocol does not protect against 1890 man-in-the-middle attacks, an attacker might be able to inject group 1891 names that are configured in NACM, so that a user gets more 1892 permissions than it should. In such cases, the administrator may 1893 wish to disable the usage of such group names, by setting /nacm/ 1894 enable-external-groups to "false". 1896 An administrator needs to restrict read access to the following 1897 objects within this data model, as they reveal access control 1898 configuration that could be considered sensitive. 1900 o /nacm/enable-nacm 1902 o /nacm/read-default 1904 o /nacm/write-default 1906 o /nacm/exec-default 1908 o /nacm/enable-external-groups 1910 o /nacm/groups 1912 o /nacm/rule-list 1914 3.7.2. General Configuration Issues 1916 There is a risk that invocation of non-standard protocol operations 1917 will have undocumented side effects. An administrator needs to 1918 construct access control rules such that the configuration datastore 1919 is protected from such side effects. 1921 It is possible for a session with some write access (e.g., allowed to 1922 invoke ), but without any access to a particular 1923 datastore subtree containing sensitive data, to determine the 1924 presence or non-presence of that data. This can be done by 1925 repeatedly issuing some sort of edit request (create, update, or 1926 delete) and possibly receiving "access-denied" errors in response. 1927 These "fishing" attacks can identify the presence or non-presence of 1928 specific sensitive data even without the "error-path" field being 1929 present within the response. 1931 It may be possible for the set of NETCONF capabilities on the server 1932 to change over time. If so, then there is a risk that new protocol 1933 operations, notifications, and/or datastore content have been added 1934 to the device. An administrator needs to be sure the access control 1935 rules are correct for the new content in this case. Mechanisms to 1936 detect NETCONF capability changes on a specific device are outside 1937 the scope of this document. 1939 It is possible that the data model definition itself (e.g., YANG 1940 when-stmt) will help an unauthorized session determine the presence 1941 or even value of sensitive data nodes by examining the presence and 1942 values of different data nodes. 1944 There is a risk that non-standard protocol operations, or even the 1945 standard protocol operation, may return data that "aliases" or 1946 "copies" sensitive data from a different data object. There may 1947 simply be multiple data model definitions that expose or even 1948 configure the same underlying system instrumentation. 1950 A data model may contain external keys (e.g., YANG leafref), which 1951 expose values from a different data structure. An administrator 1952 needs to be aware of sensitive data models that contain leafref 1953 nodes. This entails finding all the leafref objects that "point" at 1954 the sensitive data (i.e., "path-stmt" values) that implicitly or 1955 explicitly include the sensitive data node. 1957 It is beyond the scope of this document to define access control 1958 enforcement procedures for underlying device instrumentation that may 1959 exist to support the NETCONF server operation. An administrator can 1960 identify each protocol operation that the server provides and decide 1961 if it needs any access control applied to it. 1963 This document incorporates the optional use of a recovery session 1964 mechanism, which can be used to bypass access control enforcement in 1965 emergencies, such as NACM configuration errors that disable all 1966 access to the server. The configuration and identification of such a 1967 recovery session mechanism are implementation-specific and outside 1968 the scope of this document. An administrator needs to be aware of 1969 any recovery session mechanisms available on the device and make sure 1970 they are used appropriately. 1972 It is possible for a session to disrupt configuration management, 1973 even without any write access to the configuration, by locking the 1974 datastore. This may be done to ensure all or part of the 1975 configuration remains stable while it is being retrieved, or it may 1976 be done as a "denial-of-service" attack. There is no way for the 1977 server to know the difference. An administrator may wish to restrict 1978 "exec" access to the following protocol operations: 1980 o 1982 o 1984 o 1986 o 1988 3.7.3. Data Model Design Considerations 1990 Designers need to clearly identify any sensitive data, notifications, 1991 or protocol operations defined within a YANG module. For such 1992 definitions, a "nacm:default-deny-write" or "nacm:default-deny-all" 1993 statement ought to be present, in addition to a clear description of 1994 the security risks. 1996 Protocol operations need to be properly documented by the data model 1997 designer, so it is clear to administrators what data nodes (if any) 1998 are affected by the protocol operation and what information (if any) 1999 is returned in the message. 2001 Data models ought to be designed so that different access levels for 2002 input parameters to protocol operations are not required. Use of 2003 generic protocol operations should be avoided, and if different 2004 access levels are needed, separate protocol operations should be 2005 defined instead. 2007 4. References 2009 4.1. Normative References 2011 [I-D.ietf-netmod-revised-datastores] 2012 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2013 and R. Wilton, "Network Management Datastore 2014 Architecture", draft-ietf-netmod-revised-datastores-02 2015 (work in progress), May 2017. 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2018 Requirement Levels", BCP 14, RFC 2119, 2019 DOI 10.17487/RFC2119, March 1997, 2020 . 2022 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2023 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2024 . 2026 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2027 the Network Configuration Protocol (NETCONF)", RFC 6020, 2028 DOI 10.17487/RFC6020, October 2010, 2029 . 2031 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2032 and A. Bierman, Ed., "Network Configuration Protocol 2033 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2034 . 2036 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2037 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2038 . 2040 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2041 Protocol (HTTP/1.1): Message Syntax and Routing", 2042 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2043 . 2045 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2046 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2047 . 2049 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2050 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2051 . 2053 4.2. Informative References 2055 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2056 "Remote Authentication Dial In User Service (RADIUS)", 2057 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2058 . 2060 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 2061 User Service (RADIUS) Authorization for Network Access 2062 Server (NAS) Management", RFC 5607, DOI 10.17487/RFC5607, 2063 July 2009, . 2065 Appendix A. Change Log 2067 -- RFC Ed.: remove this section before publication. 2069 The NACM issue tracker can be found here: https://github.com/netconf- 2070 wg/rfc6536bis/issues 2072 A.1. v03 to v04 2074 o Fix revision date mismatch for extracting YANG module 2076 A.2. v02 to v03 2078 o Clarify NACM YANG extensions for use outside NACM 2080 A.3. v01 to v02 2082 o Corrected section title for changes since RFC 6536. 2084 o Added section 'Mapping New Datastores to NACM'. 2086 o Changed term NETCONF datastore to datastore/ 2088 o Removed text about RESTCONF and a conceptual datastore. 2090 A.4. v00 to v01 2092 o Updated RESTCONF reference 2094 A.5. v00 2096 o Renamed document from draft-bierman-netconf-rfc6536bis-01 to 2097 draft-ietf-netconf-rfc6536bis-00. 2099 Appendix B. Usage Examples 2101 The following XML snippets are provided as examples only, to 2102 demonstrate how NACM can be configured to perform some access control 2103 tasks. 2105 B.1. Example 2107 There needs to be at least one entry in order for any of the 2108 access control rules to be useful. 2110 The following XML shows arbitrary groups and is not intended to 2111 represent any particular use case. 2113 2114 2115 2116 admin 2117 admin 2118 andy 2119 2121 2122 limited 2123 wilma 2124 bam-bam 2125 2127 2128 guest 2129 guest 2130 guest@example.com 2131 2132 2133 2135 This example shows three groups: 2137 admin: The "admin" group contains two users named "admin" and 2138 "andy". 2140 limited: The "limited" group contains two users named "wilma" and 2141 "bam-bam". 2143 guest: The "guest" group contains two users named "guest" and 2144 "guest@example.com". 2146 B.2. Module Rule Example 2148 Module rules are used to control access to all the content defined in 2149 a specific module. A module rule has the leaf set, but 2150 no case in the "rule-type" choice. 2152 2153 2154 guest-acl 2155 guest 2157 2158 deny-ncm 2159 ietf-netconf-monitoring 2160 * 2161 deny 2162 2163 Do not allow guests any access to the NETCONF 2164 monitoring information. 2165 2166 2167 2169 2170 limited-acl 2171 limited 2173 2174 permit-ncm 2175 ietf-netconf-monitoring 2176 read 2177 permit 2178 2179 Allow read access to the NETCONF 2180 monitoring information. 2181 2182 2183 2184 permit-exec 2185 * 2186 exec 2187 permit 2188 2189 Allow invocation of the 2190 supported server operations. 2191 2192 2193 2195 2196 admin-acl 2197 admin 2199 2200 permit-all 2201 * 2202 * 2203 permit 2204 2205 Allow the admin group complete access to all 2206 operations and data. 2207 2208 2209 2210 2212 This example shows four module rules: 2214 deny-ncm: This rule prevents the "guest" group from reading any 2215 monitoring information in the "ietf-netconf-monitoring" YANG 2216 module. 2218 permit-ncm: This rule allows the "limited" group to read the "ietf- 2219 netconf-monitoring" YANG module. 2221 permit-exec: This rule allows the "limited" group to invoke any 2222 protocol operation supported by the server. 2224 permit-all: This rule allows the "admin" group complete access to 2225 all content in the server. No subsequent rule will match for the 2226 "admin" group because of this module rule. 2228 B.3. Protocol Operation Rule Example 2230 Protocol operation rules are used to control access to a specific 2231 protocol operation. 2233 2234 2235 guest-limited-acl 2236 limited 2237 guest 2239 2240 deny-kill-session 2241 ietf-netconf 2242 kill-session 2243 exec 2244 deny 2245 2246 Do not allow the limited or guest group 2247 to kill another session. 2248 2249 2250 2251 deny-delete-config 2252 ietf-netconf 2253 delete-config 2254 exec 2255 deny 2256 2257 Do not allow limited or guest group 2258 to delete any configurations. 2259 2260 2261 2263 2264 limited-acl 2265 limited 2267 2268 permit-edit-config 2269 ietf-netconf 2270 edit-config 2271 exec 2272 permit 2273 2274 Allow the limited group to edit the configuration. 2275 2276 2277 2279 2281 This example shows three protocol operation rules: 2283 deny-kill-session: This rule prevents the "limited" or "guest" 2284 groups from invoking the NETCONF protocol 2285 operation. 2287 deny-delete-config: This rule prevents the "limited" or "guest" 2288 groups from invoking the NETCONF protocol 2289 operation. 2291 permit-edit-config: This rule allows the "limited" group to invoke 2292 the NETCONF protocol operation. This rule will have 2293 no real effect unless the "exec-default" leaf is set to "deny". 2295 B.4. Data Node Rule Example 2297 Data node rules are used to control access to specific (config and 2298 non-config) data nodes within the NETCONF content provided by the 2299 server. 2301 2302 2303 guest-acl 2304 guest 2306 2307 deny-nacm 2308 2309 /n:nacm 2310 2311 * 2312 deny 2313 2314 Deny the guest group any access to the /nacm data. 2315 2316 2317 2319 2320 limited-acl 2321 limited 2323 2324 permit-acme-config 2325 2326 /acme:acme-netconf/acme:config-parameters 2327 2328 2329 read create update delete 2330 2331 permit 2332 2333 Allow the limited group complete access to the acme 2334 NETCONF configuration parameters. Showing long form 2335 of 'access-operations' instead of shorthand. 2336 2337 2338 2340 2341 guest-limited-acl 2342 guest 2343 limited 2345 2346 permit-dummy-interface 2347 2348 /acme:interfaces/acme:interface[acme:name='dummy'] 2349 2350 read update 2351 permit 2352 2353 Allow the limited and guest groups read 2354 and update access to the dummy interface. 2355 2356 2357 2359 2360 admin-acl 2361 admin 2362 2363 permit-interface 2364 2365 /acme:interfaces/acme:interface 2366 2367 * 2368 permit 2369 2370 Allow admin full access to all acme interfaces. 2371 2372 2373 2374 2376 This example shows four data node rules: 2378 deny-nacm: This rule denies the "guest" group any access to the 2379 subtree. Note that the default namespace is only 2380 applicable because this subtree is defined in the same namespace 2381 as the element. 2383 permit-acme-config: This rule gives the "limited" group read-write 2384 access to the acme . 2386 permit-dummy-interface: This rule gives the "limited" and "guest" 2387 groups read-update access to the acme entry named 2388 "dummy". This entry cannot be created or deleted by these groups, 2389 just altered. 2391 permit-interface: This rule gives the "admin" group read-write 2392 access to all acme entries. 2394 B.5. Notification Rule Example 2396 Notification rules are used to control access to a specific 2397 notification event type. 2399 2400 2401 sys-acl 2402 limited 2403 guest 2405 2406 deny-config-change 2407 acme-system 2408 sys-config-change 2409 read 2410 deny 2411 2412 Do not allow the guest or limited groups 2413 to receive config change events. 2414 2415 2416 2417 2419 This example shows one notification rule: 2421 deny-config-change: This rule prevents the "limited" or "guest" 2422 groups from receiving the acme event type. 2424 Authors' Addresses 2426 Andy Bierman 2427 YumaWorks 2428 685 Cochran St. 2429 Suite #160 2430 Simi Valley, CA 93065 2431 USA 2433 EMail: andy@yumaworks.com 2434 Martin Bjorklund 2435 Tail-f Systems 2437 EMail: mbj@tail-f.com