idnits 2.17.1 draft-ietf-netconf-rfc6536bis-07.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 (October 20, 2017) is 2380 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) == Missing Reference: 'RFCXXXX' is mentioned on line 1853, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-02 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 3 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: April 23, 2018 October 20, 2017 8 Network Configuration Access Control Module 9 draft-ietf-netconf-rfc6536bis-07 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 April 23, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Changes Since RFC 6536 . . . . . . . . . . . . . . . . . 6 61 2. Access Control Design Objectives . . . . . . . . . . . . . . 6 62 2.1. Access Control Points . . . . . . . . . . . . . . . . . . 6 63 2.2. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3. Procedural Interface . . . . . . . . . . . . . . . . . . 7 65 2.4. Datastore Access . . . . . . . . . . . . . . . . . . . . 8 66 2.5. Users and Groups . . . . . . . . . . . . . . . . . . . . 8 67 2.6. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 8 68 2.7. Configuration Capabilities . . . . . . . . . . . . . . . 8 69 2.8. Identifying Security-Sensitive Content . . . . . . . . . 8 70 3. NETCONF Access Control Model (NACM) . . . . . . . . . . . . . 9 71 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.1. Features . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1.2. External Dependencies . . . . . . . . . . . . . . . . 10 74 3.1.3. Message Processing Model . . . . . . . . . . . . . . 11 75 3.2. Datastore Access . . . . . . . . . . . . . . . . . . . . 14 76 3.2.1. Mapping New Datastores to NACM . . . . . . . . . . . 14 77 3.2.2. Access Rights . . . . . . . . . . . . . . . . . . . . 14 78 3.2.3. RESTCONF Methods . . . . . . . . . . . . . . . . . . 15 79 3.2.4. and Operations . . . . . . . . . . 16 80 3.2.5. Operation . . . . . . . . . . . . . . . 16 81 3.2.6. Operation . . . . . . . . . . . . . . . 17 82 3.2.7. Operation . . . . . . . . . . . . . . 18 83 3.2.8. Operation . . . . . . . . . . . . . . . . . 18 84 3.2.9. Operation . . . . . . . . . . . . . 18 85 3.2.10. Operation . . . . . . . . . . . . . . 19 86 3.3. Model Components . . . . . . . . . . . . . . . . . . . . 19 87 3.3.1. Users . . . . . . . . . . . . . . . . . . . . . . . . 19 88 3.3.2. Groups . . . . . . . . . . . . . . . . . . . . . . . 19 89 3.3.3. Emergency Recovery Session . . . . . . . . . . . . . 19 90 3.3.4. Global Enforcement Controls . . . . . . . . . . . . . 20 91 3.3.4.1. enable-nacm Switch . . . . . . . . . . . . . . . 20 92 3.3.4.2. read-default Switch . . . . . . . . . . . . . . . 20 93 3.3.4.3. write-default Switch . . . . . . . . . . . . . . 20 94 3.3.4.4. exec-default Switch . . . . . . . . . . . . . . . 21 95 3.3.4.5. enable-external-groups Switch . . . . . . . . . . 21 96 3.3.5. Access Control Rules . . . . . . . . . . . . . . . . 21 98 3.4. Access Control Enforcement Procedures . . . . . . . . . . 21 99 3.4.1. Initial Operation . . . . . . . . . . . . . . . . . . 22 100 3.4.2. Session Establishment . . . . . . . . . . . . . . . . 22 101 3.4.3. "access-denied" Error Handling . . . . . . . . . . . 22 102 3.4.4. Incoming RPC Message Validation . . . . . . . . . . . 22 103 3.4.5. Data Node Access Validation . . . . . . . . . . . . . 25 104 3.4.6. Outgoing Authorization . . . . . . . . 27 105 3.5. Data Model Definitions . . . . . . . . . . . . . . . . . 29 106 3.5.1. Data Organization . . . . . . . . . . . . . . . . . . 30 107 3.5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 30 108 3.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 109 3.7. Security Considerations . . . . . . . . . . . . . . . . . 41 110 3.7.1. NACM Configuration and Monitoring Considerations . . 41 111 3.7.2. General Configuration Issues . . . . . . . . . . . . 43 112 3.7.3. Data Model Design Considerations . . . . . . . . . . 44 113 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 114 4.1. Normative References . . . . . . . . . . . . . . . . . . 45 115 4.2. Informative References . . . . . . . . . . . . . . . . . 46 116 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 47 117 A.1. v06 to v07 . . . . . . . . . . . . . . . . . . . . . . . 47 118 A.2. v05 to v06 . . . . . . . . . . . . . . . . . . . . . . . 47 119 A.3. v04 to v05 . . . . . . . . . . . . . . . . . . . . . . . 47 120 A.4. v03 to v04 . . . . . . . . . . . . . . . . . . . . . . . 47 121 A.5. v02 to v03 . . . . . . . . . . . . . . . . . . . . . . . 47 122 A.6. v01 to v02 . . . . . . . . . . . . . . . . . . . . . . . 47 123 A.7. v00 to v01 . . . . . . . . . . . . . . . . . . . . . . . 48 124 A.8. v00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 125 Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 48 126 B.1. Example . . . . . . . . . . . . . . . . . . . . 48 127 B.2. Module Rule Example . . . . . . . . . . . . . . . . . . . 49 128 B.3. Protocol Operation Rule Example . . . . . . . . . . . . . 51 129 B.4. Data Node Rule Example . . . . . . . . . . . . . . . . . 53 130 B.5. Notification Rule Example . . . . . . . . . . . . . . . . 55 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 133 1. Introduction 135 The NETCONF and RESTCONF protocols do not provide any standard 136 mechanisms to restrict the protocol operations and content that each 137 user is authorized to access. 139 There is a need for interoperable management of the controlled access 140 to administrator-selected portions of the available NETCONF or 141 RESTCONF content within a particular server. 143 This document addresses access control mechanisms for the Operations 144 and Content layers of NETCONF, as defined in [RFC6241], and RESTCONF, 145 as defined in [RFC8040]. It contains three main sections: 147 1. Access Control Design Objectives 149 2. NETCONF Access Control Model (NACM) 151 3. YANG Data Model (ietf-netconf-acm.yang) 153 YANG version 1.1 [RFC7950] adds two new constructs that need special 154 access control handling. The "action" statement is similar to the 155 "rpc" statement, except it is located within a data node. The 156 "notification" statement can also be located within a data node. 158 1.1. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 The following terms are defined in 165 [I-D.ietf-netmod-revised-datastores] and are not redefined here: 167 o datastore 169 o configuration datastore 171 o conventional configuration datastore 173 o candidate configuration datastore 175 o running configuration datastore 177 o startup configuration datastore 179 o operational state datastore 181 o client 183 o server 185 The following terms are defined in [RFC6241] and are not redefined 186 here: 188 o protocol operation 190 o session 192 o user 193 The following terms are defined in [RFC7950] and are not redefined 194 here: 196 o action 198 o data node 200 o data definition statement 202 The following terms are defined in [RFC8040] and are not redefined 203 here: 205 o data resource 207 o datastore resource 209 o operation resource 211 o target resource 213 The following term is defined in [RFC7230] and is not redefined here: 215 o request URI 217 The following terms are used throughout this document: 219 access control: A security feature provided by the server that 220 allows an administrator to restrict access to a subset of all 221 protocol operations and data, based on various criteria. 223 access control model (ACM): A conceptual model used to configure and 224 monitor the access control procedures desired by the administrator 225 to enforce a particular access control policy. 227 access control rule: The criterion used to determine if a particular 228 access operation will be permitted or denied. 230 access operation: How a request attempts to access a conceptual 231 object. One of "none", "read", "create", "delete", "update", or 232 "execute". 234 data node hierarchy: The hierarchy of data nodes that identifies the 235 specific "action" or "notification" node in the datastore. 237 recovery session: A special administrative session that is given 238 unlimited NETCONF access and is exempt from all access control 239 enforcement. The mechanism(s) used by a server to control and 240 identify whether or not a session is a recovery session are 241 implementation specific and outside the scope of this document. 243 write access: A shorthand for the "create", "delete", and "update" 244 access operations. 246 1.2. Changes Since RFC 6536 248 The NACM procedures and data model have been updated to support new 249 data modeling capabilities in the version 1.1. of the YANG data 250 modeling language. The "action" and "notification" statements can be 251 used within data nodes to define data-model specific operations and 252 notifications. 254 An important use-case for these new YANG statements is the increased 255 access control granularity that can be achieved over top-level "rpc" 256 and "notification" statements. The new "action" and "notification" 257 statements are used within data nodes, and access to the action or 258 notification can be restricted to specific instances of these data 259 nodes. 261 Support for the RESTCONF protocol has been added. The RESTCONF 262 operations are similar to the NETCONF operations, so a simple mapping 263 to the existing NACM procedures and data model is possible. 265 2. Access Control Design Objectives 267 This section documents the design objectives for the NETCONF Access 268 Control Model presented in Section 3. 270 2.1. Access Control Points 272 NETCONF allows server implementors to add new custom protocol 273 operations, and the YANG Data Modeling Language supports this 274 feature. These operations can be defined in standard or proprietary 275 YANG modules. 277 It is not possible to design an ACM for NETCONF that only focuses on 278 a static set of standard protocol operations defined by the NETCONF 279 protocol itself, like some other protocols. Since few assumptions 280 can be made about an arbitrary protocol operation, the NETCONF 281 architectural server components need to be protected at three 282 conceptual control points. 284 These access control points, described in Figure 1, are as follows: 286 protocol operation: Permission to invoke specific protocol 287 operations. 289 datastore: Permission to read and/or alter specific data nodes 290 within any datastore. 292 notification: Permission to receive specific notification event 293 types. 295 +-------------+ +-------------+ 296 client | protocol | | data node | 297 request --> | operation | -------------> | access | 298 | allowed? | datastore | allowed? | 299 +-------------+ or state +-------------+ 300 data access 302 +----------------+ 303 | notification | 304 event --> | allowed? | 305 +----------------+ 307 Figure 1 309 2.2. Simplicity 311 There is concern that a complicated ACM will not be widely deployed 312 because it is too hard to use. It needs to be easy to do simple 313 things and possible to do complex things, instead of hard to do 314 everything. 316 Configuration of the access control system needs to be as simple as 317 possible. Simple and common tasks need to be easy to configure and 318 require little expertise or domain-specific knowledge. Complex tasks 319 are possible using additional mechanisms, which may require 320 additional expertise. 322 A single set of access control rules ought to be able to control all 323 types of NETCONF protocol operation invocation, all datastore access, 324 and all notification events. 326 Access control ought to be defined with a small and familiar set of 327 permissions, while still allowing full control of datastore access. 329 2.3. Procedural Interface 331 The NETCONF protocol uses a remote procedure call model and an 332 extensible set of protocol operations. Access control for any 333 possible protocol operation is necessary. 335 2.4. Datastore Access 337 It is necessary to control access to specific nodes and subtrees 338 within the datastore, regardless of which protocol operation, 339 standard or proprietary, was used to access the datastore. 341 2.5. Users and Groups 343 It is necessary that access control rules for a single user or a 344 configurable group of users can be configured. 346 The ACM needs to support the concept of administrative groups, to 347 support the well-established distinction between a root account and 348 other types of less-privileged conceptual user accounts. These 349 groups need to be configurable by the administrator. 351 It is necessary that the user-to-group mapping can be delegated to a 352 central server, such as a RADIUS server [RFC2865][RFC5607]. Since 353 authentication is performed by the transport layer and RADIUS 354 performs authentication and service authorization at the same time, 355 the underlying transport protocol needs to be able to report a set of 356 group names associated with the user to the server. It is necessary 357 that the administrator can disable the usage of these group names 358 within the ACM. 360 2.6. Maintenance 362 It ought to be possible to disable part or all of the access control 363 model enforcement procedures without deleting any access control 364 rules. 366 2.7. Configuration Capabilities 368 Suitable configuration and monitoring mechanisms are needed to allow 369 an administrator to easily manage all aspects of the ACM's behavior. 370 A standard data model, suitable for use with the 371 protocol operation, needs to be available for this purpose. 373 Access control rules to restrict access operations on specific 374 subtrees within the configuration datastore need to be supported. 376 2.8. Identifying Security-Sensitive Content 378 One of the most important aspects of the data model documentation, 379 and biggest concerns during deployment, is the identification of 380 security-sensitive content. This applies to protocol operations in 381 NETCONF, not just data and notifications. 383 It is mandatory for security-sensitive objects to be documented in 384 the Security Considerations section of an RFC. This is nice, but it 385 is not good enough, for the following reasons: 387 o This documentation-only approach forces administrators to study 388 the RFC and determine if there are any potential security risks 389 introduced by a new data model. 391 o If any security risks are identified, then the administrator must 392 study some more RFC text and determine how to mitigate the 393 security risk(s). 395 o The ACM on each server must be configured to mitigate the security 396 risks, e.g., require privileged access to read or write the 397 specific data identified in the Security Considerations section. 399 o If the ACM is not pre-configured, then there will be a time window 400 of vulnerability after the new data model is loaded and before the 401 new access control rules for that data model are configured, 402 enabled, and debugged. 404 Often, the administrator just wants to disable default access to the 405 secure content, so no inadvertent or malicious changes can be made to 406 the server. This allows the default rules to be more lenient, 407 without significantly increasing the security risk. 409 A data model designer needs to be able to use machine-readable 410 statements to identify content that needs to be protected by default. 411 This will allow client and server tools to automatically identify 412 data-model-specific security risks, by denying access to sensitive 413 data unless the user is explicitly authorized to perform the 414 requested access operation. 416 3. NETCONF Access Control Model (NACM) 418 3.1. Introduction 420 This section provides a high-level overview of the access control 421 model structure. It describes the NETCONF protocol message 422 processing model and the conceptual access control requirements 423 within that model. 425 3.1.1. Features 427 The NACM data model provides the following features: 429 o Independent control of remote procedure call (RPC), action, data, 430 and notification access. 432 o Simple access control rules configuration data model that is easy 433 to use. 435 o The concept of an emergency recovery session is supported, but 436 configuration of the server for this purpose is beyond the scope 437 of this document. An emergency recovery session will bypass all 438 access control enforcement, in order to allow it to initialize or 439 repair the NACM configuration. 441 o A simple and familiar set of datastore permissions is used. 443 o Support for YANG security tagging (e.g., "nacm:default-deny-write" 444 statement) allows default security modes to automatically exclude 445 sensitive data. 447 o Separate default access modes for read, write, and execute 448 permissions. 450 o Access control rules are applied to configurable groups of users. 452 o The access control enforcement procedures can be disabled during 453 operation, without deleting any access control rules, in order to 454 debug operational problems. 456 o Access control rules are simple to configure. 458 o The number of denied protocol operation requests and denied 459 datastore write requests can be monitored by the client. 461 o Simple unconstrained YANG instance identifiers are used to 462 configure access control rules for specific data nodes. 464 3.1.2. External Dependencies 466 The NETCONF protocol [RFC6241] is used for network management 467 purposes within this document. 469 The RESTCONF protocol [RFC8040] is used for network management 470 purposes within this document. 472 The YANG Data Modeling Language [RFC7950] is used to define the data 473 models for use with the NETCONF or RESTCONF protocols. YANG is also 474 used to define the data model in this document. 476 3.1.3. Message Processing Model 478 The following diagram shows the conceptual message flow model, 479 including the points at which access control is applied during 480 NETCONF message processing. 482 RESTCONF operations are mapped to the access control model based on 483 the HTTP method and resource class used in the operation. For 484 example, a POST method on a data resource is considered "write data 485 node" access, but a POST method on an operation resource is 486 considered "operation" access. 488 +-------------------------+ 489 | session | 490 | (username) | 491 +-------------------------+ 492 | ^ 493 V | 494 +--------------+ +---------------+ 495 | message | | message | 496 | dispatcher | | generator | 497 +--------------+ +---------------+ 498 | | ^ ^ 499 | V | | 500 | +=============+ | | 501 | | pre-read | | | 502 | | data node | | | 503 | | acc. ctl | | | 504 | +=============+ | | 505 | | | | 506 V V | | 507 +===========+ +-------------+ +----------------+ 508 | operation |---> | reply | | | 509 | acc. ctl | | generator | | generator | 510 +===========+ +-------------+ +----------------+ 511 | ^ ^ ^ 512 V +------+ | | 513 +-----------+ | +=============+ +================+ 514 | operation | | | read | | | 515 | processor |-+ | data node | | access ctl | 516 | | | acc. ctl | | | 517 +-----------+ +=============+ +================+ 518 | | ^ ^ ^ 519 V +----------------+ | | | 520 +===========+ | | | +============+ 521 | write | | | | | pre-read | 522 | data node | | | | | data node | 523 | acc. ctl | -----------+ | | | | acc. ctl | 524 +===========+ | | | | +============+ 525 | | | | | ^ 526 V V V | | | 527 +---------------+ +-------------------+ 528 | configuration | ---> | server | 529 | datastore | | instrumentation | 530 | | <--- | | 531 +---------------+ +-------------------+ 533 Figure 2 535 The following high-level sequence of conceptual processing steps is 536 executed for each received message, if access control 537 enforcement is enabled: 539 o For each active session, access control is applied individually to 540 all messages (except ) received by the 541 server, unless the session is identified as a recovery session. 543 o If the operation defined in [RFC7950] is invoked, then 544 read access is required for all instances in the hierarchy of data 545 nodes that identifies the specific action in the datastore, and 546 execute access is required for the action node. If the user is 547 not authorized to read all the specified data nodes and execute 548 the action, then the request is rejected with an "access-denied" 549 error. 551 o Otherwise, if the user is not authorized to execute the specified 552 protocol operation, then the request is rejected with an "access- 553 denied" error. 555 o If a datastore is accessed by the protocol operation, then the 556 server checks if the client is authorized to access the nodes in 557 the datastore. If the user is not authorized to perform the 558 requested access operation on the requested data, then the request 559 is rejected with an "access-denied" error. 561 The following sequence of conceptual processing steps is executed for 562 each generated notification event, if access control enforcement is 563 enabled: 565 o Server instrumentation generates a notification for a particular 566 subscription. 568 o If the notification statement is specified within a data subtree, 569 as specified in [RFC7950], then read access is required for all 570 instances in the hierarchy of data nodes that identifies the 571 specific notification in the datastore, and read access is 572 required for the notification node. If the user is not authorized 573 to read all the specified data nodes and the notification node, 574 then the notification is dropped for that subscription. 576 o If the notification statement is a top-level statement, the 577 notification access control enforcer checks the notification event 578 type, and if it is one that the user is not authorized to read, 579 then the notification is dropped for that subscription. 581 3.2. Datastore Access 583 The same access control rules apply to all datastores that support 584 NACM, for example, the candidate configuration datastore or the 585 running configuration datastore. 587 All conventional configuration datastores and the operational state 588 datastore are controlled by NACM. Local or remote files or 589 datastores accessed via the parameter are not controlled by 590 NACM. 592 3.2.1. Mapping New Datastores to NACM 594 It is possible that new datastores will be defined over time for use 595 with the NETCONF protocol. NACM MAY be applied to other datastores 596 that have similar access rights as defined in NACM. To apply NACM to 597 a new datastore, the new datastore specification needs to define how 598 it maps to the NACM CRUDX access rights. It is possible only a 599 subset of the NACM access rights would be applicable. For example, 600 only retrieval access control would be needed for a read-only 601 datastore. Operations and access rights not supported by the NACM 602 CRUDX model are outside the scope of this document. A datastore does 603 not need to use NACM, e.g., the datastore specification defines 604 something else, or does not use access control. 606 3.2.2. Access Rights 608 A small set of hard-wired datastore access rights is needed to 609 control access to all possible protocol operations, including vendor 610 extensions to the standard protocol operation set. 612 The "CRUDX" model can support all protocol operations: 614 o Create: allows the client to add a new data node instance to a 615 datastore. 617 o Read: allows the client to read a data node instance from a 618 datastore or receive the notification event type. 620 o Update: allows the client to update an existing data node instance 621 in a datastore. 623 o Delete: allows the client to delete a data node instance from a 624 datastore. 626 o eXec: allows the client to execute the operation. 628 3.2.3. RESTCONF Methods 630 The RESTCONF protocol utilizes HTTP methods to perform datastore 631 operations, similar to the NETCONF protocol. The NACM procedures 632 were originally written for NETCONF protocol operations so the 633 RESTCONF methods are mapped to NETCONF operations for the purpose of 634 access control processing. The enforcement procedures described 635 within this document apply to both protocols unless explicitly stated 636 otherwise. 638 The request URI needs to be considered when processing RESTCONF 639 requests on data resources: 641 o For HEAD and GET requests, any data nodes which are ancestor nodes 642 of the target resource are considered to be part of the retrieval 643 request for access control purposes. 645 o For PUT, PATCH, and DELETE requests, any data nodes which are 646 ancestor nodes of the target resource are not considered to be 647 part of the edit request for access control purposes. The access 648 operation for these nodes is considered to be "none". The edit 649 begins at the target resource. 651 o For POST requests on data resources, any data nodes which are 652 specified in the request URI, including the target resource, are 653 not considered to be part of the edit request for access control 654 purposes. The access operation for these nodes is considered to 655 be "none". The edit begins at a child node of the target 656 resource, specified in the message body. 658 Not all RESTCONF methods are subject to access control. The 659 following table specifies how each method is mapped to NETCONF 660 protocol operations. The value "none" indicates that NACM is not 661 applied at all to the specific RESTCONF method. 663 +---------+-----------------+---------------------+-----------------+ 664 | method | resource class | NETCONF operation | Access | 665 | | | | operation | 666 +---------+-----------------+---------------------+-----------------+ 667 | OPTIONS | all | none | N/A | 668 | HEAD | all | | N/A | 669 | GET | all | | N/A | 670 | POST | datastore, data | | create | 671 | POST | operation | specified operation | N/A | 672 | PUT | data | | create, replace | 673 | PUT | datastore | | replace | 674 | PATCH | data, datastore | | merge | 675 | DELETE | data | | delete | 676 +---------+-----------------+---------------------+-----------------+ 678 Table 1: Mapping RESTCONF Methods to NETCONF 680 3.2.4. and Operations 682 The NACM access rights are not directly coupled to the and 683 protocol operations, but apply to all operations 684 that would result in a "read" access operation to the target 685 datastore. This section describes how these access rights apply to 686 the specific access operations supported by the and protocol operations. 689 Data nodes to which the client does not have read access are silently 690 omitted from the message. This is done to allow NETCONF 691 filters for and to function properly, instead of 692 causing an "access-denied" error because the filter criteria would 693 otherwise include unauthorized read access to some data nodes. For 694 NETCONF filtering purposes, the selection criteria is applied to the 695 subset of nodes that the user is authorized to read, not the entire 696 datastore. 698 3.2.5. Operation 700 The NACM access rights are not directly coupled to the 701 "operation" attribute, although they are similar. Instead, a NACM 702 access right applies to all protocol operations that would result in 703 a particular access operation to the target datastore. This section 704 describes how these access rights apply to the specific access 705 operations supported by the protocol operation. 707 If the effective access operation is "none" (i.e., default- 708 operation="none") for a particular data node, then no access control 709 is applied to that data node. This is required to allow access to a 710 subtree within a larger data structure. For example, a user may be 711 authorized to create a new "/interfaces/interface" list entry but not 712 be authorized to create or delete its parent container 713 ("/interfaces"). If the "/interfaces" container already exists in 714 the target datastore, then the effective operation will be "none" for 715 the "/interfaces" node if an "/interfaces/interface" list entry is 716 edited. 718 If the protocol operation would result in the creation of a datastore 719 node and the user does not have "create" access permission for that 720 node, the protocol operation is rejected with an "access-denied" 721 error. 723 If the protocol operation would result in the deletion of a datastore 724 node and the user does not have "delete" access permission for that 725 node, the protocol operation is rejected with an "access-denied" 726 error. 728 If the protocol operation would result in the modification of a 729 datastore node and the user does not have "update" access permission 730 for that node, the protocol operation is rejected with an "access- 731 denied" error. 733 A "merge" or "replace" operation may include data nodes 734 that do not alter portions of the existing datastore. For example, a 735 container or list node may be present for naming purposes but does 736 not actually alter the corresponding datastore node. These unaltered 737 data nodes are ignored by the server and do not require any access 738 rights by the client. 740 A "merge" operation may include data nodes but not 741 include particular child data nodes that are present in the 742 datastore. These missing data nodes within the scope of a "merge" 743 operation are ignored by the server and do not require 744 any access rights by the client. 746 The contents of specific restricted datastore nodes MUST NOT be 747 exposed in any elements within the reply. 749 3.2.6. Operation 751 Access control for the protocol operation requires 752 special consideration because the administrator may be replacing the 753 entire target datastore. 755 If the source of the protocol operation is the running 756 configuration datastore and the target is the startup configuration 757 datastore, the client is only required to have permission to execute 758 the protocol operation. 760 Otherwise: 762 o If the source of the operation is a datastore, then 763 data nodes to which the client does not have read access are 764 silently omitted. 766 o If the target of the operation is a datastore, the 767 client needs access to the modified nodes, specifically: 769 * If the protocol operation would result in the creation of a 770 datastore node and the user does not have "create" access 771 permission for that node, the protocol operation is rejected 772 with an "access-denied" error. 774 * If the protocol operation would result in the deletion of a 775 datastore node and the user does not have "delete" access 776 permission for that node, the protocol operation is rejected 777 with an "access-denied" error. 779 * If the protocol operation would result in the modification of a 780 datastore node and the user does not have "update" access 781 permission for that node, the protocol operation is rejected 782 with an "access-denied" error. 784 3.2.7. Operation 786 Access to the protocol operation is denied by 787 default. The "exec-default" leaf does not apply to this protocol 788 operation. Access control rules must be explicitly configured to 789 allow invocation by a non-recovery session. 791 3.2.8. Operation 793 The server MUST determine the exact nodes in the running 794 configuration datastore that are actually different and only check 795 "create", "update", and "delete" access permissions for this set of 796 nodes, which could be empty. 798 For example, if a session can read the entire datastore but only 799 change one leaf, that session needs to be able to edit and commit 800 that one leaf. 802 3.2.9. Operation 804 The client is only required to have permission to execute the 805 protocol operation. No datastore permissions are 806 needed. 808 3.2.10. Operation 810 The operation does not directly alter a datastore. 811 However, it allows one session to disrupt another session that is 812 editing a datastore. 814 Access to the protocol operation is denied by default. 815 The "exec-default" leaf does not apply to this protocol operation. 816 Access control rules must be explicitly configured to allow 817 invocation by a non-recovery session. 819 3.3. Model Components 821 This section defines the conceptual components related to the access 822 control model. 824 3.3.1. Users 826 A "user" is the conceptual entity that is associated with the access 827 permissions granted to a particular session. A user is identified by 828 a string that is unique within the server. 830 As described in [RFC6241], the username string is derived from the 831 transport layer during session establishment. If the transport layer 832 cannot authenticate the user, the session is terminated. 834 3.3.2. Groups 836 Access to a specific NETCONF protocol operation is granted to a 837 session, associated with a group, not a user. 839 A group is identified by its name. All group names are unique within 840 the server. 842 A group member is identified by a username string. 844 The same user can be a member of multiple groups. 846 3.3.3. Emergency Recovery Session 848 The server MAY support a recovery session mechanism, which will 849 bypass all access control enforcement. This is useful for 850 restricting initial access and repairing a broken access control 851 configuration. 853 3.3.4. Global Enforcement Controls 855 There are five global controls that are used to help control how 856 access control is enforced. 858 3.3.4.1. enable-nacm Switch 860 A global "enable-nacm" on/off switch is provided to enable or disable 861 all access control enforcement. When this global switch is set to 862 "true", then all requests are checked against the access control 863 rules and only permitted if configured to allow the specific access 864 request. When this global switch is set to "false", then all access 865 requested are permitted. 867 3.3.4.2. read-default Switch 869 An on/off "read-default" switch is provided to enable or disable 870 default access to receive data in replies and notifications. When 871 the "enable-nacm" global switch is set to "true", then this global 872 switch is relevant if no matching access control rule is found to 873 explicitly permit or deny read access to the requested datastore data 874 or notification event type. 876 When this global switch is set to "permit" and no matching access 877 control rule is found for the datastore read or notification event 878 requested, then access is permitted. 880 When this global switch is set to "deny" and no matching access 881 control rule is found for the datastore read or notification event 882 requested, then access is denied. 884 3.3.4.3. write-default Switch 886 An on/off "write-default" switch is provided to enable or disable 887 default access to alter configuration data. When the "enable-nacm" 888 global switch is set to "true", then this global switch is relevant 889 if no matching access control rule is found to explicitly permit or 890 deny write access to the requested datastore data. 892 When this global switch is set to "permit" and no matching access 893 control rule is found for the datastore write requested, then access 894 is permitted. 896 When this global switch is set to "deny" and no matching access 897 control rule is found for the datastore write requested, then access 898 is denied. 900 3.3.4.4. exec-default Switch 902 An on/off "exec-default" switch is provided to enable or disable 903 default access to execute protocol operations. When the "enable- 904 nacm" global switch is set to "true", then this global switch is 905 relevant if no matching access control rule is found to explicitly 906 permit or deny access to the requested NETCONF protocol operation. 908 When this global switch is set to "permit" and no matching access 909 control rule is found for the NETCONF protocol operation requested, 910 then access is permitted. 912 When this global switch is set to "deny" and no matching access 913 control rule is found for the NETCONF protocol operation requested, 914 then access is denied. 916 3.3.4.5. enable-external-groups Switch 918 When this global switch is set to "true", the group names reported by 919 the transport layer for a session are used together with the locally 920 configured group names to determine the access control rules for the 921 session. 923 When this switch is set to "false", the group names reported by the 924 transport layer are ignored by NACM. 926 3.3.5. Access Control Rules 928 There are four types of rules available in NACM: 930 module rule: controls access for definitions in a specific YANG 931 module, identified by its name. 933 protocol operation rule: controls access for a specific protocol 934 operation, identified by its YANG module and name. 936 data node rule: controls access for a specific data node, identified 937 by its path location within the conceptual XML document for the 938 data node. 940 notification rule: controls access for a specific notification event 941 type, identified by its YANG module and name. 943 3.4. Access Control Enforcement Procedures 945 There are seven separate phases that need to be addressed, four of 946 which are related to the NETCONF message processing model 947 (Section 3.1.3). In addition, the initial startup mode for a NETCONF 948 server, session establishment, and "access-denied" error-handling 949 procedures also need to be considered. 951 The server MUST use the access control rules in effect at the time it 952 starts processing the message. The same access control rules MUST 953 stay in effect for the processing of the entire message. 955 3.4.1. Initial Operation 957 Upon the very first startup of the NETCONF server, the access control 958 configuration will probably not be present. If it isn't, a server 959 MUST NOT allow any write access to any session role except a recovery 960 session. 962 Access rules are enforced any time a request is initiated from a user 963 session. Access control is not enforced for server-initiated access 964 requests, such as the initial load of the running configuration 965 datastore, during bootup. 967 3.4.2. Session Establishment 969 The access control model applies specifically to the well-formed XML 970 content transferred between a client and a server after session 971 establishment has been completed and after the exchange has 972 been successfully completed. 974 Once session establishment is completed and a user has been 975 authenticated, the transport layer reports the username and a 976 possibly empty set of group names associated with the user to the 977 NETCONF server. The NETCONF server will enforce the access control 978 rules, based on the supplied username, group names, and the 979 configuration data stored on the server. 981 3.4.3. "access-denied" Error Handling 983 The "access-denied" error-tag is generated when the access control 984 system denies access to either a request to invoke a protocol 985 operation or a request to perform a particular access operation on 986 the configuration datastore. 988 A server MUST NOT include any information the client is not allowed 989 to read in any elements within the response. 991 3.4.4. Incoming RPC Message Validation 993 The diagram below shows the basic conceptual structure of the access 994 control processing model for incoming NETCONF messages within a 995 server. 997 NETCONF server 998 +------------+ 999 | XML | 1000 | message | 1001 | dispatcher | 1002 +------------+ 1003 | 1004 | 1005 V 1006 +------------+ 1007 | NC-base NS | 1008 | | 1009 +------------+ 1010 | | | 1011 | | +-------------------------+ 1012 | +------------+ | 1013 V V V 1014 +-----------+ +---------------+ +------------+ 1015 | Vendor NS | | NC-base NS | | NC-base NS | 1016 | | | | | | 1017 +-----------+ +---------------+ +------------+ 1018 | | 1019 | | 1020 V V 1021 +----------------------+ 1022 | | 1023 | configuration | 1024 | datastore | 1025 +----------------------+ 1027 Figure 3 1029 Access control begins with the message dispatcher. 1031 After the server validates the element and determines the 1032 namespace URI and the element name of the protocol operation being 1033 requested, the server verifies that the user is authorized to invoke 1034 the protocol operation. 1036 The server MUST separately authorize every protocol operation by 1037 following these steps: 1039 1. If the "enable-nacm" leaf is set to "false", then the protocol 1040 operation is permitted. 1042 2. If the requesting session is identified as a recovery session, 1043 then the protocol operation is permitted. 1045 3. If the requested operation is the NETCONF 1046 protocol operation, then the protocol operation is permitted. 1048 4. Check all the "group" entries for ones that contain a "user- 1049 name" entry that equals the username for the session making the 1050 request. If the "enable-external-groups" leaf is "true", add to 1051 these groups the set of groups provided by the transport layer. 1053 5. If no groups are found, continue with step 10. 1055 6. Process all rule-list entries, in the order they appear in the 1056 configuration. If a rule-list's "group" leaf-list does not 1057 match any of the user's groups, proceed to the next rule-list 1058 entry. 1060 7. For each rule-list entry found, process all rules, in order, 1061 until a rule that matches the requested access operation is 1062 found. A rule matches if all of the following criteria are met: 1064 * The rule's "module-name" leaf is "*" or equals the name of 1065 the YANG module where the protocol operation is defined. 1067 * The rule does not have a "rule-type" defined or the "rule- 1068 type" is "protocol-operation" and the "rpc-name" is "*" or 1069 equals the name of the requested protocol operation. 1071 * The rule's "access-operations" leaf has the "exec" bit set or 1072 has the special value "*". 1074 8. If a matching rule is found, then the "action" leaf is checked. 1075 If it is equal to "permit", then the protocol operation is 1076 permitted; otherwise, it is denied. 1078 9. At this point, no matching rule was found in any rule-list 1079 entry. 1081 10. If the requested protocol operation is defined in a YANG module 1082 advertised in the server capabilities and the "rpc" statement 1083 contains a "nacm:default-deny-all" statement, then the protocol 1084 operation is denied. 1086 11. If the requested protocol operation is the NETCONF or , then the protocol operation is 1088 denied. 1090 12. If the "exec-default" leaf is set to "permit", then permit the 1091 protocol operation; otherwise, deny the request. 1093 If the user is not authorized to invoke the protocol operation, then 1094 an is generated with the following information: 1096 error-tag: access-denied 1098 error-path: Identifies the requested protocol operation. The 1099 following example represents the protocol operation 1100 in the NETCONF base namespace: 1102 1104 /nc:rpc/nc:edit-config 1105 1107 If a datastore is accessed, either directly or as a side effect of 1108 the protocol operation, then the server MUST intercept the access 1109 operation and make sure the user is authorized to perform the 1110 requested access operation on the specified data, as defined in 1111 Section 3.4.5. 1113 3.4.5. Data Node Access Validation 1115 If a data node within a datastore is accessed, or an action or 1116 notification tied to a data node, then the server MUST ensure that 1117 the user is authorized to perform the requested "read", "create", 1118 "update", "delete", or "execute" access operation on the specified 1119 data node. 1121 If an action is requested to be executed, the server MUST ensure that 1122 the user is authorized to perform the "execute" access operation on 1123 the requested action. 1125 If a notification tied to a data node is generated, the server MUST 1126 ensure that the user is authorized to perform the "read" access 1127 operation on the requested notification. 1129 The data node access request is authorized by following these steps: 1131 1. If the "enable-nacm" leaf is set to "false", then the access 1132 operation is permitted. 1134 2. If the requesting session is identified as a recovery session, 1135 then the access operation is permitted. 1137 3. Check all the "group" entries for ones that contain a "user- 1138 name" entry that equals the username for the session making the 1139 request. If the "enable-external-groups" leaf is "true", add to 1140 these groups the set of groups provided by the transport layer. 1142 4. If no groups are found, continue with step 9. 1144 5. Process all rule-list entries, in the order they appear in the 1145 configuration. If a rule-list's "group" leaf-list does not 1146 match any of the user's groups, proceed to the next rule-list 1147 entry. 1149 6. For each rule-list entry found, process all rules, in order, 1150 until a rule that matches the requested access operation is 1151 found. A rule matches if all of the following criteria are met: 1153 * The rule's "module-name" leaf is "*" or equals the name of 1154 the YANG module where the requested data node is defined. 1156 * The rule does not have a "rule-type" defined or the "rule- 1157 type" is "data-node" and the "path" matches the requested 1158 data node, action node, or notification node. 1160 * For a "read" access operation, the rule's "access-operations" 1161 leaf has the "read" bit set or has the special value "*". 1163 * For a "create" access operation, the rule's "access- 1164 operations" leaf has the "create" bit set or has the special 1165 value "*". 1167 * For a "delete" access operation, the rule's "access- 1168 operations" leaf has the "delete" bit set or has the special 1169 value "*". 1171 * For an "update" access operation, the rule's "access- 1172 operations" leaf has the "update" bit set or has the special 1173 value "*". 1175 * For an "execute" access operation, the rule's "access- 1176 operations" leaf has the "exec" bit set or has the special 1177 value "*". 1179 7. If a matching rule is found, then the "action" leaf is checked. 1180 If it is equal to "permit", then the data node access is 1181 permitted; otherwise, it is denied. For a "read" access 1182 operation, "denied" means that the requested data is not 1183 returned in the reply. 1185 8. At this point, no matching rule was found in any rule-list 1186 entry. 1188 9. For a "read" access operation, if the requested data node is 1189 defined in a YANG module advertised in the server capabilities 1190 and the data definition statement contains a "nacm:default-deny- 1191 all" statement, then the requested data node is not included in 1192 the reply. 1194 10. For a "write" access operation, if the requested data node is 1195 defined in a YANG module advertised in the server capabilities 1196 and the data definition statement contains a "nacm:default-deny- 1197 write" or a "nacm:default-deny-all" statement, then the data 1198 node access request is denied. 1200 11. For a "read" access operation, if the "read-default" leaf is set 1201 to "permit", then include the requested data node in the reply; 1202 otherwise, do not include the requested data node in the reply. 1204 12. For a "write" access operation, if the "write-default" leaf is 1205 set to "permit", then permit the data node access request; 1206 otherwise, deny the request. 1208 13. For an "execute" access operation, if the "exec-default" leaf is 1209 set to "permit", then permit the request; otherwise, deny the 1210 request. 1212 3.4.6. Outgoing Authorization 1214 Configuration of access control rules specifically for descendant 1215 nodes of the notification event type element are outside the scope of 1216 this document. If the user is authorized to receive the notification 1217 event type, then it is also authorized to receive any data it 1218 contains. 1220 If the notification is specified within a data subtree, as specified 1221 in [RFC7950], then read access to the notification is required. 1222 Processing continues as described in Section 3.4.5. 1224 The following figure shows the conceptual message processing model 1225 for outgoing messages. 1227 NETCONF server 1228 +------------+ 1229 | XML | 1230 | message | 1231 | generator | 1232 +------------+ 1233 ^ 1234 | 1235 +----------------+ 1236 | | 1237 | generator | 1238 +----------------+ 1239 ^ 1240 | 1241 +=================+ 1242 | | 1243 | access control | 1244 | | 1245 +=================+ 1246 ^ 1247 | 1248 +------------------------+ 1249 | server instrumentation | 1250 +------------------------+ 1251 | ^ 1252 V | 1253 +----------------------+ 1254 | configuration | 1255 | datastore | 1256 +----------------------+ 1258 Figure 4 1260 The generation of a notification for a specific subscription 1261 [RFC5277] is authorized by following these steps: 1263 1. If the "enable-nacm" leaf is set to "false", then the 1264 notification is permitted. 1266 2. If the session is identified as a recovery session, then the 1267 notification is permitted. 1269 3. If the notification is the NETCONF or 1270 event type [RFC5277], then the 1271 notification is permitted. 1273 4. Check all the "group" entries for ones that contain a "user- 1274 name" entry that equals the username for the session making the 1275 request. If the "enable-external-groups" leaf is "true", add to 1276 these groups the set of groups provided by the transport layer. 1278 5. If no groups are found, continue with step 10. 1280 6. Process all rule-list entries, in the order they appear in the 1281 configuration. If a rule-list's "group" leaf-list does not 1282 match any of the user's groups, proceed to the next rule-list 1283 entry. 1285 7. For each rule-list entry found, process all rules, in order, 1286 until a rule that matches the requested access operation is 1287 found. A rule matches if all of the following criteria are met: 1289 * The rule's "module-name" leaf is "*" or equals the name of 1290 the YANG module where the notification is defined. 1292 * The rule does not have a "rule-type" defined or the "rule- 1293 type" is "notification" and the "notification-name" is "*" or 1294 equals the name of the notification. 1296 * The rule's "access-operations" leaf has the "read" bit set or 1297 has the special value "*". 1299 8. If a matching rule is found, then the "action" leaf is checked. 1300 If it is equal to "permit", then permit the notification; 1301 otherwise, drop the notification for the associated 1302 subscription. 1304 9. Otherwise, no matching rule was found in any rule-list entry. 1306 10. If the requested notification is defined in a YANG module 1307 advertised in the server capabilities and the "notification" 1308 statement contains a "nacm:default-deny-all" statement, then the 1309 notification is dropped for the associated subscription. 1311 11. If the "read-default" leaf is set to "permit", then permit the 1312 notification; otherwise, drop the notification for the 1313 associated subscription. 1315 3.5. Data Model Definitions 1316 3.5.1. Data Organization 1318 The following diagram highlights the contents and structure of the 1319 NACM YANG module. 1321 module: ietf-netconf-acm 1322 +--rw nacm 1323 +--rw enable-nacm? boolean 1324 +--rw read-default? action-type 1325 +--rw write-default? action-type 1326 +--rw exec-default? action-type 1327 +--rw enable-external-groups? boolean 1328 +--ro denied-operations yang:zero-based-counter32 1329 +--ro denied-data-writes yang:zero-based-counter32 1330 +--ro denied-notifications yang:zero-based-counter32 1331 +--rw groups 1332 | +--rw group* [name] 1333 | +--rw name group-name-type 1334 | +--rw user-name* user-name-type 1335 +--rw rule-list* [name] 1336 +--rw name string 1337 +--rw group* union 1338 +--rw rule* [name] 1339 +--rw name string 1340 +--rw module-name? union 1341 +--rw (rule-type)? 1342 | +--:(protocol-operation) 1343 | | +--rw rpc-name? union 1344 | +--:(notification) 1345 | | +--rw notification-name? union 1346 | +--:(data-node) 1347 | +--rw path node-instance-identifier 1348 +--rw access-operations? union 1349 +--rw action action-type 1350 +--rw comment? string 1352 3.5.2. YANG Module 1354 The following YANG module specifies the normative NETCONF content 1355 that MUST by supported by the server. 1357 The "ietf-netconf-acm" YANG module imports typedefs from [RFC6991]. 1359 file "ietf-netconf-acm@2017-10-20.yang" 1360 module ietf-netconf-acm { 1362 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm"; 1363 prefix "nacm"; 1365 import ietf-yang-types { 1366 prefix yang; 1367 } 1369 organization 1370 "IETF NETCONF (Network Configuration) Working Group"; 1372 contact 1373 "WG Web: 1374 WG List: 1376 Author: Andy Bierman 1377 1379 Author: Martin Bjorklund 1380 "; 1382 description 1383 "Network Configuration Access Control Model. 1385 Copyright (c) 2012, 2017 IETF Trust and the persons 1386 identified as authors of the code. All rights reserved. 1388 Redistribution and use in source and binary forms, with or 1389 without modification, is permitted pursuant to, and subject 1390 to the license terms contained in, the Simplified BSD 1391 License set forth in Section 4.c of the IETF Trust's 1392 Legal Provisions Relating to IETF Documents 1393 (http://trustee.ietf.org/license-info). 1395 This version of this YANG module is part of RFC XXXX; see 1396 the RFC itself for full legal notices."; 1398 revision "2017-10-20" { 1399 description 1400 "Added support for YANG 1.1 actions and notifications tied to 1401 data nodes. Clarify how NACM extensions can be used by other 1402 data models."; 1403 reference 1404 "RFC XXXX: Network Configuration Protocol (NETCONF) 1405 Access Control Model"; 1406 } 1408 revision "2012-02-22" { 1409 description 1410 "Initial version"; 1411 reference 1412 "RFC 6536: Network Configuration Protocol (NETCONF) 1413 Access Control Model"; 1414 } 1416 /* 1417 * Extension statements 1418 */ 1420 extension default-deny-write { 1421 description 1422 "Used to indicate that the data model node 1423 represents a sensitive security system parameter. 1425 If present, the NETCONF server will only allow the designated 1426 'recovery session' to have write access to the node. An 1427 explicit access control rule is required for all other users. 1429 If the NACM module is used, then it must be enabled (i.e., 1430 /nacm/enable-nacm object equals 'true'), or this extension 1431 is ignored. 1433 The 'default-deny-write' extension MAY appear within a data 1434 definition statement. It is ignored otherwise."; 1435 } 1437 extension default-deny-all { 1438 description 1439 "Used to indicate that the data model node 1440 controls a very sensitive security system parameter. 1442 If present, the NETCONF server will only allow the designated 1443 'recovery session' to have read, write, or execute access to the 1444 node. An explicit access control rule is required for all other 1445 users. 1447 If the NACM module is used, then it must be enabled (i.e., 1448 /nacm/enable-nacm object equals 'true'), or this extension 1449 is ignored. 1451 The 'default-deny-all' extension MAY appear within a data 1452 definition statement, 'rpc' statement, or 'notification' 1453 statement. It is ignored otherwise."; 1454 } 1456 /* 1457 * Derived types 1458 */ 1460 typedef user-name-type { 1461 type string { 1462 length "1..max"; 1463 } 1464 description 1465 "General Purpose Username string."; 1466 } 1468 typedef matchall-string-type { 1469 type string { 1470 pattern '\*'; 1471 } 1472 description 1473 "The string containing a single asterisk '*' is used 1474 to conceptually represent all possible values 1475 for the particular leaf using this data type."; 1476 } 1478 typedef access-operations-type { 1479 type bits { 1480 bit create { 1481 description 1482 "Any protocol operation that creates a 1483 new data node."; 1484 } 1485 bit read { 1486 description 1487 "Any protocol operation or notification that 1488 returns the value of a data node."; 1489 } 1490 bit update { 1491 description 1492 "Any protocol operation that alters an existing 1493 data node."; 1494 } 1495 bit delete { 1496 description 1497 "Any protocol operation that removes a data node."; 1498 } 1499 bit exec { 1500 description 1501 "Execution access to the specified protocol operation."; 1502 } 1503 } 1504 description 1505 "Access Operation."; 1507 } 1509 typedef group-name-type { 1510 type string { 1511 length "1..max"; 1512 pattern '[^\*].*'; 1513 } 1514 description 1515 "Name of administrative group to which 1516 users can be assigned."; 1517 } 1519 typedef action-type { 1520 type enumeration { 1521 enum permit { 1522 description 1523 "Requested action is permitted."; 1524 } 1525 enum deny { 1526 description 1527 "Requested action is denied."; 1528 } 1529 } 1530 description 1531 "Action taken by the server when a particular 1532 rule matches."; 1533 } 1535 typedef node-instance-identifier { 1536 type yang:xpath1.0; 1537 description 1538 "Path expression used to represent a special 1539 data node, action, or notification instance identifier 1540 string. 1542 A node-instance-identifier value is an 1543 unrestricted YANG instance-identifier expression. 1544 All the same rules as an instance-identifier apply 1545 except predicates for keys are optional. If a key 1546 predicate is missing, then the node-instance-identifier 1547 represents all possible server instances for that key. 1549 This XPath expression is evaluated in the following context: 1551 o The set of namespace declarations are those in scope on 1552 the leaf element where this type is used. 1554 o The set of variable bindings contains one variable, 1555 'USER', which contains the name of the user of the current 1556 session. 1558 o The function library is the core function library, but 1559 note that due to the syntax restrictions of an 1560 instance-identifier, no functions are allowed. 1562 o The context node is the root node in the data tree. 1564 The accessible tree includes actions and notifications tied 1565 to data nodes."; 1566 } 1568 /* 1569 * Data definition statements 1570 */ 1572 container nacm { 1573 nacm:default-deny-all; 1575 description 1576 "Parameters for NETCONF Access Control Model."; 1578 leaf enable-nacm { 1579 type boolean; 1580 default true; 1581 description 1582 "Enables or disables all NETCONF access control 1583 enforcement. If 'true', then enforcement 1584 is enabled. If 'false', then enforcement 1585 is disabled."; 1586 } 1588 leaf read-default { 1589 type action-type; 1590 default "permit"; 1591 description 1592 "Controls whether read access is granted if 1593 no appropriate rule is found for a 1594 particular read request."; 1595 } 1597 leaf write-default { 1598 type action-type; 1599 default "deny"; 1600 description 1601 "Controls whether create, update, or delete access 1602 is granted if no appropriate rule is found for a 1603 particular write request."; 1604 } 1606 leaf exec-default { 1607 type action-type; 1608 default "permit"; 1609 description 1610 "Controls whether exec access is granted if no appropriate 1611 rule is found for a particular protocol operation request."; 1612 } 1614 leaf enable-external-groups { 1615 type boolean; 1616 default true; 1617 description 1618 "Controls whether the server uses the groups reported by the 1619 NETCONF transport layer when it assigns the user to a set of 1620 NACM groups. If this leaf has the value 'false', any group 1621 names reported by the transport layer are ignored by the 1622 server."; 1623 } 1625 leaf denied-operations { 1626 type yang:zero-based-counter32; 1627 config false; 1628 mandatory true; 1629 description 1630 "Number of times since the server last restarted that a 1631 protocol operation request was denied."; 1632 } 1634 leaf denied-data-writes { 1635 type yang:zero-based-counter32; 1636 config false; 1637 mandatory true; 1638 description 1639 "Number of times since the server last restarted that a 1640 protocol operation request to alter 1641 a configuration datastore was denied."; 1642 } 1644 leaf denied-notifications { 1645 type yang:zero-based-counter32; 1646 config false; 1647 mandatory true; 1648 description 1649 "Number of times since the server last restarted that 1650 a notification was dropped for a subscription because 1651 access to the event type was denied."; 1652 } 1654 container groups { 1655 description 1656 "NETCONF Access Control Groups."; 1658 list group { 1659 key name; 1661 description 1662 "One NACM Group Entry. This list will only contain 1663 configured entries, not any entries learned from 1664 any transport protocols."; 1666 leaf name { 1667 type group-name-type; 1668 description 1669 "Group name associated with this entry."; 1670 } 1672 leaf-list user-name { 1673 type user-name-type; 1674 description 1675 "Each entry identifies the username of 1676 a member of the group associated with 1677 this entry."; 1678 } 1679 } 1680 } 1682 list rule-list { 1683 key "name"; 1684 ordered-by user; 1685 description 1686 "An ordered collection of access control rules."; 1688 leaf name { 1689 type string { 1690 length "1..max"; 1691 } 1692 description 1693 "Arbitrary name assigned to the rule-list."; 1694 } 1695 leaf-list group { 1696 type union { 1697 type matchall-string-type; 1698 type group-name-type; 1700 } 1701 description 1702 "List of administrative groups that will be 1703 assigned the associated access rights 1704 defined by the 'rule' list. 1706 The string '*' indicates that all groups apply to the 1707 entry."; 1708 } 1710 list rule { 1711 key "name"; 1712 ordered-by user; 1713 description 1714 "One access control rule. 1716 Rules are processed in user-defined order until a match is 1717 found. A rule matches if 'module-name', 'rule-type', and 1718 'access-operations' match the request. If a rule 1719 matches, the 'action' leaf determines if access is granted 1720 or not."; 1722 leaf name { 1723 type string { 1724 length "1..max"; 1725 } 1726 description 1727 "Arbitrary name assigned to the rule."; 1728 } 1730 leaf module-name { 1731 type union { 1732 type matchall-string-type; 1733 type string; 1734 } 1735 default "*"; 1736 description 1737 "Name of the module associated with this rule. 1739 This leaf matches if it has the value '*' or if the 1740 object being accessed is defined in the module with the 1741 specified module name."; 1742 } 1743 choice rule-type { 1744 description 1745 "This choice matches if all leafs present in the rule 1746 match the request. If no leafs are present, the 1747 choice matches all requests."; 1749 case protocol-operation { 1750 leaf rpc-name { 1751 type union { 1752 type matchall-string-type; 1753 type string; 1754 } 1755 description 1756 "This leaf matches if it has the value '*' or if 1757 its value equals the requested protocol operation 1758 name."; 1759 } 1760 } 1761 case notification { 1762 leaf notification-name { 1763 type union { 1764 type matchall-string-type; 1765 type string; 1766 } 1767 description 1768 "This leaf matches if it has the value '*' or if its 1769 value equals the requested notification name."; 1770 } 1771 } 1772 case data-node { 1773 leaf path { 1774 type node-instance-identifier; 1775 mandatory true; 1776 description 1777 "Data Node Instance Identifier associated with the 1778 data node, action, or notification controlled by 1779 this rule. 1781 Configuration data or state data instance 1782 identifiers start with a top-level data node. A 1783 complete instance identifier is required for this 1784 type of path value. 1786 The special value '/' refers to all possible 1787 datastore contents."; 1788 } 1789 } 1790 } 1792 leaf access-operations { 1793 type union { 1794 type matchall-string-type; 1795 type access-operations-type; 1796 } 1797 default "*"; 1798 description 1799 "Access operations associated with this rule. 1801 This leaf matches if it has the value '*' or if the 1802 bit corresponding to the requested operation is set."; 1803 } 1805 leaf action { 1806 type action-type; 1807 mandatory true; 1808 description 1809 "The access control action associated with the 1810 rule. If a rule is determined to match a 1811 particular request, then this object is used 1812 to determine whether to permit or deny the 1813 request."; 1814 } 1816 leaf comment { 1817 type string; 1818 description 1819 "A textual description of the access rule."; 1820 } 1821 } 1822 } 1823 } 1824 } 1826 1828 Figure 5 1830 3.6. IANA Considerations 1832 This document reuses the URI for "ietf-netconf-acm" in "The IETF XML 1833 Registry". 1835 This document updates the module registration in the "YANG Module 1836 Names" registry to reference this RFC instead of RFC 6536. Following 1837 the format in [RFC6020], the following has been registered. 1839 Name: ietf-netconf-acm 1840 Namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-acm 1841 Prefix: nacm 1842 reference: RFC XXXX 1844 3.7. Security Considerations 1846 The YANG module defined in this document is designed to be accessed 1847 via network management protocols such as NETCONF [RFC6241] or 1848 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 1849 layer, and the mandatory-to-implement secure transport is Secure 1850 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 1851 mandatory-to-implement secure transport is TLS [RFC5246]. 1853 The NETCONF access control model [RFCXXXX] provides the means to 1854 restrict access for particular NETCONF or RESTCONF users to a 1855 preconfigured subset of all available NETCONF or RESTCONF protocol 1856 operations and content. 1858 There are a number of data nodes defined in this YANG module that are 1859 writable/creatable/deletable (i.e., config true, which is the 1860 default). These data nodes may be considered sensitive or vulnerable 1861 in some network environments. Write operations (e.g., edit-config) 1862 to these data nodes without proper protection can have a negative 1863 effect on network operations. These are the subtrees and data nodes 1864 and their sensitivity/vulnerability: 1866 o /nacm : the entire /nacm subtree is related to security. Refer to 1867 the following sections for more details. 1869 This section highlights the issues for an administrator to consider 1870 when configuring a NETCONF server with NACM. 1872 3.7.1. NACM Configuration and Monitoring Considerations 1874 Configuration of the access control system is highly sensitive to 1875 system security. A server may choose not to allow any user 1876 configuration to some portions of it, such as the global security 1877 level or the groups that allowed access to system resources. 1879 By default, NACM enforcement is enabled. By default, "read" access 1880 to all datastore contents is enabled (unless "nacm:default-deny-all" 1881 is specified for the data definition), and "exec" access is enabled 1882 for safe protocol operations. An administrator needs to ensure that 1883 NACM is enabled and also decide if the default access parameters are 1884 set appropriately. Make sure the following data nodes are properly 1885 configured: 1887 o /nacm/enable-nacm (default "true") 1889 o /nacm/read-default (default "permit") 1891 o /nacm/write-default (default "deny") 1892 o /nacm/exec-default (default "permit") 1894 An administrator needs to restrict write access to all configurable 1895 objects within this data model. 1897 If write access is allowed for configuration of access control rules, 1898 then care needs to be taken not to disrupt the access control 1899 enforcement. For example, if the NACM access control rules are 1900 edited directly within the running configuration datastore (i.e., 1901 :writable-running capability is supported and used), then care needs 1902 to be taken not to allow unintended access while the edits are being 1903 done. 1905 An administrator needs to make sure that the translation from a 1906 transport- or implementation-dependent user identity to a NACM 1907 username is unique and correct. This requirement is specified in 1908 detail in Section 2.2 of [RFC6241]. 1910 An administrator needs to be aware that the YANG data structures 1911 representing access control rules (/nacm/rule-list and /nacm/rule- 1912 list/rule) are ordered by the client. The server will evaluate the 1913 access control rules according to their relative conceptual order 1914 within the running configuration datastore. 1916 Note that the /nacm/groups data structure contains the administrative 1917 group names used by the server. These group names may be configured 1918 locally and/or provided through an external protocol, such as RADIUS 1919 [RFC2865][RFC5607]. 1921 An administrator needs to be aware of the security properties of any 1922 external protocol used by the transport layer to determine group 1923 names. For example, if this protocol does not protect against man- 1924 in-the-middle attacks, an attacker might be able to inject group 1925 names that are configured in NACM, so that a user gets more 1926 permissions than it should. In such cases, the administrator may 1927 wish to disable the usage of such group names, by setting /nacm/ 1928 enable-external-groups to "false". 1930 An administrator needs to restrict read access to the following 1931 objects within this data model, as they reveal access control 1932 configuration that could be considered sensitive. 1934 o /nacm/enable-nacm 1936 o /nacm/read-default 1938 o /nacm/write-default 1939 o /nacm/exec-default 1941 o /nacm/enable-external-groups 1943 o /nacm/groups 1945 o /nacm/rule-list 1947 3.7.2. General Configuration Issues 1949 There is a risk that invocation of non-standard protocol operations 1950 will have undocumented side effects. An administrator needs to 1951 construct access control rules such that the configuration datastore 1952 is protected from such side effects. 1954 It is possible for a session with some write access (e.g., allowed to 1955 invoke ), but without any access to a particular 1956 datastore subtree containing sensitive data, to determine the 1957 presence or non-presence of that data. This can be done by 1958 repeatedly issuing some sort of edit request (create, update, or 1959 delete) and possibly receiving "access-denied" errors in response. 1960 These "fishing" attacks can identify the presence or non-presence of 1961 specific sensitive data even without the "error-path" field being 1962 present within the response. 1964 It may be possible for the set of NETCONF capabilities on the server 1965 to change over time. If so, then there is a risk that new protocol 1966 operations, notifications, and/or datastore content have been added 1967 to the device. An administrator needs to be sure the access control 1968 rules are correct for the new content in this case. Mechanisms to 1969 detect NETCONF capability changes on a specific device are outside 1970 the scope of this document. 1972 It is possible that the data model definition itself (e.g., YANG 1973 when-stmt) will help an unauthorized session determine the presence 1974 or even value of sensitive data nodes by examining the presence and 1975 values of different data nodes. 1977 There is a risk that non-standard protocol operations, or even the 1978 standard protocol operation, may return data that "aliases" or 1979 "copies" sensitive data from a different data object. There may 1980 simply be multiple data model definitions that expose or even 1981 configure the same underlying system instrumentation. 1983 A data model may contain external keys (e.g., YANG leafref), which 1984 expose values from a different data structure. An administrator 1985 needs to be aware of sensitive data models that contain leafref 1986 nodes. This entails finding all the leafref objects that "point" at 1987 the sensitive data (i.e., "path-stmt" values) that implicitly or 1988 explicitly include the sensitive data node. 1990 It is beyond the scope of this document to define access control 1991 enforcement procedures for underlying device instrumentation that may 1992 exist to support the NETCONF server operation. An administrator can 1993 identify each protocol operation that the server provides and decide 1994 if it needs any access control applied to it. 1996 This document incorporates the optional use of a recovery session 1997 mechanism, which can be used to bypass access control enforcement in 1998 emergencies, such as NACM configuration errors that disable all 1999 access to the server. The configuration and identification of such a 2000 recovery session mechanism are implementation-specific and outside 2001 the scope of this document. An administrator needs to be aware of 2002 any recovery session mechanisms available on the device and make sure 2003 they are used appropriately. 2005 It is possible for a session to disrupt configuration management, 2006 even without any write access to the configuration, by locking the 2007 datastore. This may be done to ensure all or part of the 2008 configuration remains stable while it is being retrieved, or it may 2009 be done as a "denial-of-service" attack. There is no way for the 2010 server to know the difference. An administrator may wish to restrict 2011 "exec" access to the following protocol operations: 2013 o 2015 o 2017 o 2019 o 2021 3.7.3. Data Model Design Considerations 2023 Designers need to clearly identify any sensitive data, notifications, 2024 or protocol operations defined within a YANG module. For such 2025 definitions, a "nacm:default-deny-write" or "nacm:default-deny-all" 2026 statement ought to be present, in addition to a clear description of 2027 the security risks. 2029 Protocol operations need to be properly documented by the data model 2030 designer, so it is clear to administrators what data nodes (if any) 2031 are affected by the protocol operation and what information (if any) 2032 is returned in the message. 2034 Data models ought to be designed so that different access levels for 2035 input parameters to protocol operations are not required. Use of 2036 generic protocol operations should be avoided, and if different 2037 access levels are needed, separate protocol operations should be 2038 defined instead. 2040 4. References 2042 4.1. Normative References 2044 [I-D.ietf-netmod-revised-datastores] 2045 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2046 and R. Wilton, "Network Management Datastore 2047 Architecture", draft-ietf-netmod-revised-datastores-02 2048 (work in progress), May 2017. 2050 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2051 Requirement Levels", BCP 14, RFC 2119, 2052 DOI 10.17487/RFC2119, March 1997, . 2055 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2056 (TLS) Protocol Version 1.2", RFC 5246, 2057 DOI 10.17487/RFC5246, August 2008, . 2060 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2061 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 2062 . 2064 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2065 the Network Configuration Protocol (NETCONF)", RFC 6020, 2066 DOI 10.17487/RFC6020, October 2010, . 2069 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2070 and A. Bierman, Ed., "Network Configuration Protocol 2071 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2072 . 2074 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2075 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2076 . 2078 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2079 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2080 . 2082 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2083 Protocol (HTTP/1.1): Message Syntax and Routing", 2084 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2085 . 2087 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2088 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2089 . 2091 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2092 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2093 . 2095 4.2. Informative References 2097 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2098 "Remote Authentication Dial In User Service (RADIUS)", 2099 RFC 2865, DOI 10.17487/RFC2865, June 2000, 2100 . 2102 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 2103 User Service (RADIUS) Authorization for Network Access 2104 Server (NAS) Management", RFC 5607, DOI 10.17487/RFC5607, 2105 July 2009, . 2107 Appendix A. Change Log 2109 -- RFC Ed.: remove this section before publication. 2111 The NACM issue tracker can be found here: https://github.com/netconf- 2112 wg/rfc6536bis/issues 2114 A.1. v06 to v07 2116 o Clarify CRUDX protocol operation mapping 2118 A.2. v05 to v06 2120 o Change title to remove the word NETCONF 2122 o Clarify data rule case in YANG module 2124 o Update security considerations section 2126 A.3. v04 to v05 2128 o Clarify NETCONF protocol operation vs added operation via 2129 additional YANG modules 2131 o Change term 'NETCONF transport layer' to 'transport layer' 2133 o Clarify that read access operations are not coupled to specific 2134 protocol operations 2136 o Update date of YANG module so it matches new revision date 2138 A.4. v03 to v04 2140 o Fix revision date mismatch for extracting YANG module 2142 A.5. v02 to v03 2144 o Clarify NACM YANG extensions for use outside NACM 2146 A.6. v01 to v02 2148 o Corrected section title for changes since RFC 6536. 2150 o Added section 'Mapping New Datastores to NACM'. 2152 o Changed term NETCONF datastore to datastore/ 2153 o Removed text about RESTCONF and a conceptual datastore. 2155 A.7. v00 to v01 2157 o Updated RESTCONF reference 2159 A.8. v00 2161 o Renamed document from draft-bierman-netconf-rfc6536bis-01 to 2162 draft-ietf-netconf-rfc6536bis-00. 2164 Appendix B. Usage Examples 2166 The following XML snippets are provided as examples only, to 2167 demonstrate how NACM can be configured to perform some access control 2168 tasks. 2170 B.1. Example 2172 There needs to be at least one entry in order for any of the 2173 access control rules to be useful. 2175 The following XML shows arbitrary groups and is not intended to 2176 represent any particular use case. 2178 2179 2180 2181 admin 2182 admin 2183 andy 2184 2186 2187 limited 2188 wilma 2189 bam-bam 2190 2192 2193 guest 2194 guest 2195 guest@example.com 2196 2197 2198 2200 This example shows three groups: 2202 admin: The "admin" group contains two users named "admin" and 2203 "andy". 2205 limited: The "limited" group contains two users named "wilma" and 2206 "bam-bam". 2208 guest: The "guest" group contains two users named "guest" and 2209 "guest@example.com". 2211 B.2. Module Rule Example 2213 Module rules are used to control access to all the content defined in 2214 a specific module. A module rule has the leaf set, but 2215 no case in the "rule-type" choice. 2217 2218 2219 guest-acl 2220 guest 2222 2223 deny-ncm 2224 ietf-netconf-monitoring 2225 * 2226 deny 2227 2228 Do not allow guests any access to the NETCONF 2229 monitoring information. 2230 2231 2232 2234 2235 limited-acl 2236 limited 2238 2239 permit-ncm 2240 ietf-netconf-monitoring 2241 read 2242 permit 2243 2244 Allow read access to the NETCONF 2245 monitoring information. 2246 2247 2248 2249 permit-exec 2250 * 2251 exec 2252 permit 2253 2254 Allow invocation of the 2255 supported server operations. 2256 2257 2258 2260 2261 admin-acl 2262 admin 2264 2265 permit-all 2266 * 2267 * 2268 permit 2269 2270 Allow the admin group complete access to all 2271 operations and data. 2272 2273 2274 2275 2277 This example shows four module rules: 2279 deny-ncm: This rule prevents the "guest" group from reading any 2280 monitoring information in the "ietf-netconf-monitoring" YANG 2281 module. 2283 permit-ncm: This rule allows the "limited" group to read the "ietf- 2284 netconf-monitoring" YANG module. 2286 permit-exec: This rule allows the "limited" group to invoke any 2287 protocol operation supported by the server. 2289 permit-all: This rule allows the "admin" group complete access to 2290 all content in the server. No subsequent rule will match for the 2291 "admin" group because of this module rule. 2293 B.3. Protocol Operation Rule Example 2295 Protocol operation rules are used to control access to a specific 2296 protocol operation. 2298 2299 2300 guest-limited-acl 2301 limited 2302 guest 2304 2305 deny-kill-session 2306 ietf-netconf 2307 kill-session 2308 exec 2309 deny 2310 2311 Do not allow the limited or guest group 2312 to kill another session. 2313 2314 2315 2316 deny-delete-config 2317 ietf-netconf 2318 delete-config 2319 exec 2320 deny 2321 2322 Do not allow limited or guest group 2323 to delete any configurations. 2324 2325 2326 2328 2329 limited-acl 2330 limited 2332 2333 permit-edit-config 2334 ietf-netconf 2335 edit-config 2336 exec 2337 permit 2338 2339 Allow the limited group to edit the configuration. 2340 2341 2342 2344 2346 This example shows three protocol operation rules: 2348 deny-kill-session: This rule prevents the "limited" or "guest" 2349 groups from invoking the NETCONF protocol 2350 operation. 2352 deny-delete-config: This rule prevents the "limited" or "guest" 2353 groups from invoking the NETCONF protocol 2354 operation. 2356 permit-edit-config: This rule allows the "limited" group to invoke 2357 the NETCONF protocol operation. This rule will have 2358 no real effect unless the "exec-default" leaf is set to "deny". 2360 B.4. Data Node Rule Example 2362 Data node rules are used to control access to specific (config and 2363 non-config) data nodes within the NETCONF content provided by the 2364 server. 2366 2367 2368 guest-acl 2369 guest 2371 2372 deny-nacm 2373 2374 /n:nacm 2375 2376 * 2377 deny 2378 2379 Deny the guest group any access to the /nacm data. 2380 2381 2382 2384 2385 limited-acl 2386 limited 2388 2389 permit-acme-config 2390 2391 /acme:acme-netconf/acme:config-parameters 2392 2393 2394 read create update delete 2395 2396 permit 2397 2398 Allow the limited group complete access to the acme 2399 NETCONF configuration parameters. Showing long form 2400 of 'access-operations' instead of shorthand. 2401 2402 2403 2405 2406 guest-limited-acl 2407 guest 2408 limited 2410 2411 permit-dummy-interface 2412 2413 /acme:interfaces/acme:interface[acme:name='dummy'] 2414 2415 read update 2416 permit 2417 2418 Allow the limited and guest groups read 2419 and update access to the dummy interface. 2420 2421 2422 2424 2425 admin-acl 2426 admin 2427 2428 permit-interface 2429 2430 /acme:interfaces/acme:interface 2431 2432 * 2433 permit 2434 2435 Allow admin full access to all acme interfaces. 2436 2437 2438 2439 2441 This example shows four data node rules: 2443 deny-nacm: This rule denies the "guest" group any access to the 2444 subtree. Note that the default namespace is only 2445 applicable because this subtree is defined in the same namespace 2446 as the element. 2448 permit-acme-config: This rule gives the "limited" group read-write 2449 access to the acme . 2451 permit-dummy-interface: This rule gives the "limited" and "guest" 2452 groups read-update access to the acme entry named 2453 "dummy". This entry cannot be created or deleted by these groups, 2454 just altered. 2456 permit-interface: This rule gives the "admin" group read-write 2457 access to all acme entries. 2459 B.5. Notification Rule Example 2461 Notification rules are used to control access to a specific 2462 notification event type. 2464 2465 2466 sys-acl 2467 limited 2468 guest 2470 2471 deny-config-change 2472 acme-system 2473 sys-config-change 2474 read 2475 deny 2476 2477 Do not allow the guest or limited groups 2478 to receive config change events. 2479 2480 2481 2482 2484 This example shows one notification rule: 2486 deny-config-change: This rule prevents the "limited" or "guest" 2487 groups from receiving the acme event type. 2489 Authors' Addresses 2491 Andy Bierman 2492 YumaWorks 2493 685 Cochran St. 2494 Suite #160 2495 Simi Valley, CA 93065 2496 USA 2498 EMail: andy@yumaworks.com 2499 Martin Bjorklund 2500 Tail-f Systems 2502 EMail: mbj@tail-f.com