idnits 2.17.1 draft-bierman-netconf-access-control-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 4, 2010) is 5039 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) == Unused Reference: 'I-D.ietf-netmod-yang-types' is defined on line 2205, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4741 (Obsoleted by RFC 6241) ** Obsolete normative reference: RFC 4742 (Obsoleted by RFC 6242) 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 InterWorking Labs 4 Intended status: Standards Track M. Bjorklund 5 Expires: January 5, 2011 Tail-f Systems 6 July 4, 2010 8 Network Configuration Protocol Access Control Model 9 draft-bierman-netconf-access-control-02 11 Abstract 13 The standardization of network configuration interfaces for use with 14 the NETCONF protocol requires a structured and secure operating 15 environment, which promotes human usability and multi-vendor 16 interoperability. There is a need for standard mechanisms to 17 restrict NETCONF protocol access for particular users to a pre- 18 configured subset of all available NETCONF operations and content. 19 This document discusses requirements for a suitable access control 20 model, and provides one solution which meets these requirements. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 5, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.1.1. Requirements Notation . . . . . . . . . . . . . . . . 5 71 1.1.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . 5 72 1.1.3. NACM Terms . . . . . . . . . . . . . . . . . . . . . . 6 73 2. Authentication Requirements . . . . . . . . . . . . . . . . . 7 74 3. Access Control Requirements . . . . . . . . . . . . . . . . . 8 75 3.1. Protocol Control Points . . . . . . . . . . . . . . . . . 8 76 3.2. Simplicity . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.3. Procedural Interface . . . . . . . . . . . . . . . . . . . 9 78 3.4. Database Access . . . . . . . . . . . . . . . . . . . . . 9 79 3.4.1. Access Rights . . . . . . . . . . . . . . . . . . . . 10 80 3.4.2. and Operations . . . . . . . . . . 10 81 3.4.3. Operation . . . . . . . . . . . . . . . 10 82 3.4.4. Operation . . . . . . . . . . . . . . . 11 83 3.5. Users and Groups . . . . . . . . . . . . . . . . . . . . . 12 84 3.6. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.7. Configuration Capabilities . . . . . . . . . . . . . . . . 12 86 3.8. Identifying Security Holes . . . . . . . . . . . . . . . . 13 87 3.9. Data Shadowing . . . . . . . . . . . . . . . . . . . . . . 13 88 3.10. NETCONF Specific Requirements . . . . . . . . . . . . . . 14 89 4. NETCONF Authentication and Authorization Model . . . . . . . . 15 90 4.1. SSH Public Key Authentication . . . . . . . . . . . . . . 15 91 4.2. Local User Password Authentication . . . . . . . . . . . . 16 92 4.3. RADIUS Password Authentication and Service 93 Authorization . . . . . . . . . . . . . . . . . . . . . . 16 94 4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . 16 95 5. NETCONF Access Control Model (NACM) . . . . . . . . . . . . . 18 96 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 18 97 5.1.1. Features . . . . . . . . . . . . . . . . . . . . . . . 18 98 5.1.2. External Dependencies . . . . . . . . . . . . . . . . 19 99 5.1.3. Message Processing Model . . . . . . . . . . . . . . . 19 100 5.2. Model Components . . . . . . . . . . . . . . . . . . . . . 21 101 5.2.1. Users . . . . . . . . . . . . . . . . . . . . . . . . 21 102 5.2.2. Groups . . . . . . . . . . . . . . . . . . . . . . . . 22 103 5.2.3. Sessions . . . . . . . . . . . . . . . . . . . . . . . 22 104 5.2.4. Access Permissions . . . . . . . . . . . . . . . . . . 22 105 5.2.5. Global Enforcement Controls . . . . . . . . . . . . . 23 106 5.2.6. Access Control Rules . . . . . . . . . . . . . . . . . 23 107 5.3. Access Control Enforcement Procedures . . . . . . . . . . 23 108 5.3.1. Initial Operation . . . . . . . . . . . . . . . . . . 24 109 5.3.2. Session Establishment . . . . . . . . . . . . . . . . 24 110 5.3.3. 'access-denied' Error Handling . . . . . . . . . . . . 24 111 5.3.4. Incoming RPC Message Validation . . . . . . . . . . . 24 112 5.3.5. Data Node Access Validation . . . . . . . . . . . . . 27 113 5.3.6. Outgoing Authorization . . . . . . . . . . 29 114 5.3.7. Outgoing Authorization . . . . . . . . 30 115 5.4. Data Model Definitions . . . . . . . . . . . . . . . . . . 33 116 5.4.1. High Level Procedures . . . . . . . . . . . . . . . . 33 117 5.4.2. Data Organization . . . . . . . . . . . . . . . . . . 33 118 5.4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 34 119 5.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 49 120 5.6. Security Considerations . . . . . . . . . . . . . . . . . 49 121 6. Normative References . . . . . . . . . . . . . . . . . . . . . 51 122 Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 52 123 A.1. Example . . . . . . . . . . . . . . . . . . . . . 52 124 A.2. Example . . . . . . . . . . . . . . . . . . 53 125 A.3. Example . . . . . . . . . . . . . . . . . . . . 54 126 A.4. Example . . . . . . . . . . . . . . . . . . . 56 127 A.5. Example . . . . . . . . . . . . . . . 58 128 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 59 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 131 1. Introduction 133 The NETCONF protocol does not provide any standard mechanisms to 134 restrict the operations and content that each user is authorized to 135 use. 137 There is a need for inter-operable management of the controlled 138 access to operator selected portions of the available NETCONF content 139 within a particular server. 141 This document addresses NETCONF protocol authentication and access 142 control mechanisms for the Operation and Content layers, as defined 143 in [RFC4741], and [RFC5277]. It contains five main sections: 145 1. Authentication Requirements 147 2. Access Control Requirements 149 3. NETCONF Authentication and Authorization Model 151 4. NETCONF Access Control Model (NACM) 153 5. YANG Data Model (nacm.yang) 155 1.1. Terminology 157 1.1.1. Requirements Notation 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 1.1.2. NETCONF Terms 165 The following terms are defined in RFC 4741 and are not redefined 166 here: 168 o client 170 o operation 172 o RPC operation 174 o server 176 o session 177 o user 179 1.1.3. NACM Terms 181 The following terms are used throughout this documentation: 183 access control: A security feature provided by the NETCONF server, 184 which allows an operator to restrict access to a subset of all 185 NETCONF protocol operations and data, based on various criteria. 187 access control model (ACM): A conceptual model used to configure and 188 monitor the access control procedures desired by the operator to 189 enforce a particular access control policy. 191 access control rule: The conceptual criteria used to determine if a 192 particular NETCONF protocol operation should be permitted or 193 denied. 195 authentication: The process of verifying a user's identity. 197 superuser: The special administrative user account which is given 198 unlimited NETCONF access, and is exempt from all access control 199 enforcement. 201 2. Authentication Requirements 203 The authentication mechanism must support password authentication 204 over RADIUS, to support deployment scenarios with centralized 205 authentication servers. Additionally, local users must be supported, 206 for scenarios when no centralized authentication server exists, or 207 for situations where the centralized authentication server cannot be 208 reached from the device. 210 Since the mandatory transport protocol for NETCONF is SSH NETCONF 211 Over SSH [RFC4742], the authentication model must support SSH's 212 "publickey" and "password" authentication methods [RFC4252] 214 The model for authentication configuration should be flexible enough 215 to support authentication methods defined by other standard documents 216 or by vendors. 218 3. Access Control Requirements 220 3.1. Protocol Control Points 222 The NETCONF protocol allows new operations to be added at any time, 223 and the YANG data modeling language supports this feature. It is not 224 possible to design an ACM for NETCONF which only focuses on a static 225 set of operations, like some other protocols. Since few assumptions 226 can be made about an arbitrary protocol operation, the NETCONF 227 architectural server components must be protected at several 228 conceptual control points. 230 +-------------+ +-------------+ 231 client | RPC | | prune | client 232 request --> | operation | | restricted | ---> reply 233 | allowed? | | | 234 +-------------+ | nodes? | 235 | +-------------+ 236 | if any database or 237 | state data is accessed 238 | by the operation 239 V 240 +-------------+ +----------------+ 241 | data node | | prune | 242 | access | | restricted | 243 | allowed? | | | ---> client 244 +-------------+ | event or data? | session 245 +----------------+ 247 Figure 1 249 The following access control points are defined: 251 RPC operation: Configurable permission to invoke specific RPC 252 operations is required. Wildcard or multiple target mechanisms to 253 reduce configuration and effort are also required. 255 NETCONF database: Configurable permission to read and/or alter 256 specific data nodes within any conceptual database is required. 257 Wildcard or multiple target mechanisms to reduce configuration and 258 effort are also required. 260 RPC Reply Content: Configurable permission to read specific data 261 nodes within any conceptual RPC output section is required. 262 Unauthorized data is silently omitted from the reply, instead of 263 dropping the reply or sending an 'access-denied' error. 265 Notification Content: Configurable permission to receive specific 266 notification event types is required. 268 3.2. Simplicity 270 Experience has shown that a complicated ACM will not be widely 271 deployed, because it is too hard to use. The key factor that is 272 ignored in such solutions is the concept of 'localized cost'. It 273 should be easy to do simple things, and hard to do complex things, 274 instead of hard to do everything. 276 Configuration of the access control system must be simple to use. 277 Simple and common tasks should be easy to configure, and require 278 little expertise or domain-specific knowledge. Complex tasks should 279 be possible using additional mechanisms which may require additional 280 expertise. 282 A single set of access control rules should be able to control all 283 types of NETCONF RPC operation invocation, all conceptual database 284 access, and all NETCONF session output. 286 Default access control policy needs to be as secure as possible. 288 Protocol access should be defined with a small and familiar set of 289 permissions, while still allowing full control of NETCONF database 290 access. 292 Access control does not need to be applied to NETCONF 293 messages. 295 3.3. Procedural Interface 297 The NETCONF protocol uses a procedural interface model, and an 298 extensible set of protocol operations. Access control for any 299 possible protocol operation is required. 301 It must be possible to configure the ACM to permit or deny access to 302 specific NETCONF operations. 304 YANG modules should be designed so that different access levels for 305 input parameters to RPC operations is not required. 307 3.4. Database Access 309 It must be possible control access to specific nodes and sub-trees 310 within the conceptual NETCONF database. 312 In order for a user to obtain access to a particular database node, 313 the user must be authorized to have the same requested access to the 314 specified node, and all of its ancestors. 316 The same access control rules apply to all conceptual databases. For 317 example, the candidate configuration or the running configuration. 319 Only the standard NETCONF databases (candidate, running, and startup) 320 are controlled by the ACM. Local or remote files or databases 321 accessed via the parameter are optional to support. 323 The non-volatile startup configuration needs to be loaded into the 324 running configuration without applying any access control rules. 326 Only a privileged user should be able to alter the factory-default 327 access control rules. 329 3.4.1. Access Rights 331 A small set of hard-wired database access rights is needed to control 332 access to all possible NETCONF database operations, including vendor 333 extensions to the standard operation set. 335 The familiar 'CRUDX' model can support all NETCONF operations: 337 o Create: Allows the client to add a new data node instance to a 338 database. 340 o Read: Allows the client to read a data node instance from a 341 database, or receive the notification event type. 343 o Update: Allows the client to update an existing data node instance 344 in a database. 346 o Delete: Allows the client to delete a data node instance from a 347 database. 349 o eXec: Allows the client to execute the protocol operation. 351 3.4.2. and Operations 353 Read operations for restricted configuration data, either directly or 354 via wildcard access, are silently omitted from the 355 message. 357 3.4.3. Operation 359 The NACM access rights are not directly coupled to the NETCONF 360 operation attribute, although they are similar. Instead, a NACM 361 access right applies to all operations which would result in a 362 particular access operation to the target database. This section 363 describes how these access rights apply to the specific database 364 operations supported by the operation. 366 If the effective operation is 'none' (i.e., default-operation='none') 367 for a particular data node, then no access control is applied to that 368 data node. 370 A 'create', 'merge', or 'replace' operation on a database node which 371 would result in the creation of a new data node instance, for which 372 the user does not have 'create' access permission, is rejected with 373 an 'access-denied' error. 375 A 'merge' or 'replace' operation on a database node which would 376 result in the modification of an existing data node instance, for 377 which the user does not have 'update' access permission, is rejected 378 with an 'access-denied' error. 380 A 'replace' or 'delete' operation on a database node which would 381 result in the deletion of an existing data node instance, for which 382 the user does not have 'delete' access permission, is rejected with 383 an 'access-denied' error. 385 A 'merge' operation may include data nodes which do not alter 386 portions of the existing database. For example, a container or list 387 nodes may be present for naming purposes, which do not actually alter 388 the corresponding database node. These unaltered data nodes within 389 the scope of a 'merge' operation are ignored by the server, and do 390 not require any access rights by the client. 392 A 'merge' operation may include data nodes, but not include 393 particular child data nodes that are present in the database. These 394 missing data nodes within the scope of a 'merge' operation are 395 ignored by the server, and do not require any access rights by the 396 client. 398 The contents of specific restricted database nodes must not be 399 exposed in any elements within the reply. 401 3.4.4. Operation 403 Access control for the operation requires special 404 consideration because the operator is replacing the entire target 405 database. Write access to the entire database is needed for this 406 operation to succeed. 408 A client must have access to every database node, even ones that are 409 not present in the source configuration data. 411 For example, consider a common use-case such as a simple backup and 412 restore procedure. The operator must have full read access to the 413 database in order to receive a complete copy of its contents. If 414 not, the server will simply omit these sub-trees from the reply. If 415 that copy is later used to restore the server database, the server 416 will interpret the missing nodes as a request to delete those nodes, 417 and return an error. 419 3.5. Users and Groups 421 The server must obtain a user name from the underlying NETCONF 422 transport, such as an SSH user name. 424 It must be possible to specify access control rules for a single user 425 or a configurable group of users. 427 A configurable superuser account is needed which bypasses all access 428 control rules. This is needed in case the access control rules are 429 mis-configured, and all access is denied. 431 The ACM must support the concept of administrative groups, to support 432 the well-established distinction between a root account and other 433 types of less-privileged conceptual user accounts. These groups must 434 be configurable by the operator. 436 3.6. Maintenance 438 It should be possible to disable part or all of the access control 439 model without deleting any configuration. By default, only the 440 'superuser' should be able to perform this task. 442 It should be possible to configure a 'superuser' account so that all 443 access control is disabled for just this user. This allows the 444 access control rules to always be modified without completely 445 disabling access control for all users. 447 3.7. Configuration Capabilities 449 Suitable control and monitoring mechanisms are needed to allow an 450 operator to easily manage all aspects of the ACM behavior. A 451 standard data model, suitable for use with the 452 operation must be available for this purpose. 454 Access control rules to restrict operations on specific sub-trees 455 within the configuration database must be supported. Existing 456 mechanisms should be used to identify the sub-tree(s) for this 457 purpose. 459 3.8. Identifying Security Holes 461 One of the most important aspects of the data model documentation, 462 and biggest concerns during deployment, is the identification of 463 security-sensitive content. This applies to operations in NETCONF, 464 not just data and notifications. 466 It is customary for security-sensitive objects to be documented in 467 the Security Considerations section of an RFC. This is nice, but it 468 is not good enough, for the following reasons: 470 o This documentation-only approach forces operators to study the RFC 471 and determine if there are any potential security holes introduced 472 by a new YANG module. 474 o If any security holes are identified, then the operator must study 475 some more RFC text, and determine how to close the security 476 hole(s). 478 o The ACM on each server must be configured to close the security 479 holes, e.g., require privileged access to read or write the 480 specific data identified in the Security Considerations section. 482 o If the ACM is not pre-configured, then there will be a time window 483 of vulnerability, after the new module is loaded, and before the 484 new access control rules for that module are configured, enabled, 485 and debugged. 487 Often, the operator just wants to disable default access to the 488 secure content, so no inadvertent or malicious changes can be made to 489 the server. This allows the default rules to be more lenient, 490 without significantly increasing the security risk. 492 A data model designer should be able to use machine-readable 493 statements to identity NETCONF content which should be protected by 494 default. This will allow client and server tools to automatically 495 close data-model specific security holes, by denying access to 496 sensitive data unless the user is explicitly authorized to perform 497 the requested operation. 499 3.9. Data Shadowing 501 One of the more complicated security administration problems is 502 identifying data nodes which shadow or mirror the content of another 503 data node. An access control rule to prevent read operations for a 504 particular node may be insufficient to prevent access to the data 505 node with the copied value. 507 If the YANG leafref data type is used, then this data shadowing can 508 be detected by applications (and the server stack), and prevented. 510 If the description statement, other documentation, or no 511 documentation exists to identify a data shadow problem, then it may 512 not be detected. 514 Since NETCONF allows any vendor operation to be added to the 515 protocol, there is no way to reliably identify all of the operations 516 that may expose copies of sensitive data nodes in 517 messages. 519 A NETCONF server must insure than unauthorized access to its 520 conceptual databases and non-configuration data nodes is prevented. 522 It is beyond the scope of this document to define access control 523 enforcement procedures for underlying device instrumentation that may 524 exist to support the NETCONF server operation. An operator must 525 identify each operation that the server provides, and decide if it 526 needs any access control applied to it. 528 Proprietary protocol operations should be properly documented by the 529 vendor, so it is clear to operators what data nodes (if any) are 530 affected by the operation, and what information (if any) is returned 531 in the message. 533 3.10. NETCONF Specific Requirements 535 The server must be able to identify the specific protocol access 536 request at the 4 access control points defined above. 538 The server must be able to identify any database access request, even 539 for proprietary operations. 541 A session must always be authorized to invoke the 542 operation, defined in [RFC4741]. 544 A session must always be authorized to receive the 545 and notification events, defined in [RFC5277] 547 The set of module name strings used within one particular server must 548 be unique. 550 Within a single server, the module namespace URI associated with a 551 specific module name string must persist across a reboot, and never 552 change, once assigned. 554 4. NETCONF Authentication and Authorization Model 556 This document defines three authentication methods for use with 557 NETCONF: 559 publickey for local users over SSH 560 password for local users over any transport 561 password for RADIUS users over any transport 563 Additional methods may be defined by other standard documents or by 564 vendors. 566 Conceptually, the NETCONF transport subsystem authenticates the user, 567 and passes the name of the authenticated user to the NETCONF server. 568 The NETCONF server authorizes the user by mapping it to one or more 569 groups. Access to specific operations and content is then controlled 570 by access control rules as described in Section 5. 572 Some protocols, such as RADIUS, performs both authentication and 573 authorization, and has a mechanism to report authorization attributes 574 to the client. These attributes are made available to the NETCONF 575 server in an implementation specific manner. 577 This document defines two optional YANG features, 'local-users' and 578 'radius', which the server advertises to indicate support for 579 configuring local users on the device, and for configuring RADIUS 580 access, respectively. 582 4.1. SSH Public Key Authentication 584 If the NETCONF server advertises the 'local-users' feature, 585 configuration of local users and their SSH public keys is supported 586 in the /nacm/authentication/user list. 588 Public key authentication is requested by the SSH client. The SSH 589 server looks up the user name provided by the client in the /nacm/ 590 authentication/user list, and verifies the key as described in 591 [RFC4253]. 593 If the 'local-users' feature is supported, then when a NETCONF client 594 starts an SSH session towards the server, using the "publickey" 595 authentication 'method name' [RFC4252], the SSH server looks up the 596 user name given in the SSH authentication request in the /nacm/ 597 authentication/user list, 599 4.2. Local User Password Authentication 601 If the NETCONF server advertises the 'local-users' feature, 602 configuration of local users and their passwords is supported in the 603 /nacm/authentication/user list. 605 For NETCONF transport protocols that support password authentication, 606 the leaf-list 'user-authentication-order' is used to control if local 607 user password authentication should be used. 609 In SSH, password authentication is requested by the client. Other 610 NETCONF transport protocols may also support password authentication. 612 When local user password authentication is requested, the NETCONF 613 transport looks up the user name provided by the client in the /nacm/ 614 authentication/user list, and verifies the password. 616 4.3. RADIUS Password Authentication and Service Authorization 618 If the NETCONF server advertises the 'radius' feature, it supports 619 user authentication and service authorization with RADIUS, as 620 described in this section. 622 For NETCONF transport protocols that support password authentication, 623 the leaf-list 'user-authentication-order' is used to control if 624 RADIUS password authentication should be used. 626 In SSH, password authentication is requested by the client. Other 627 NETCONF transport protocols may also support password authentication. 629 4.3.1. Operation 631 [Editor's Note: I prefer to keep this section short, and just refer 632 to the relevant rfcs which have detailed information on radius usage, 633 instead of duplicating this info here...] 635 When RADIUS user authentication is requested, the NETCONF transport 636 subsystem acts as a RADIUS client. In the Access-Request request 637 [RFC2865], the following RADIUS attributes SHOULD be sent by the 638 client [RFC5607]: 640 o Service-Type with the value Framed-Management 642 o Framed-Management-Protocol with the value NETCONF 644 o Management-Transport-Protection with the value Integrity- 645 Confidentiality-Protection 647 As described in RFC 5607, if an Access-Accept message is received 648 which does not authorize the requested service, access MUST be 649 denied. 651 If any Management-Policy-Id attributes are present in the Access- 652 Accept message, they are treated as group names in the access control 653 procedure, as described in Section 5. 655 The following RADIUS attributes MAY be sent by the RADIUS server: 657 o Session-Timeout 659 o Idle-Timeout 661 See [RFC2865] for a description of these attributes. These timeout 662 values MUST be enforced by the NETCONF server. 664 5. NETCONF Access Control Model (NACM) 666 5.1. Introduction 668 This section provides a high-level overview of the access control 669 model structure. It describes the NETCONF protocol message 670 processing model, and the conceptual access control requirements 671 within that model. 673 5.1.1. Features 675 The NACM data model provides the following features: 677 o Independent control of RPC, data, and notification access. 679 o Very simple access control rules configuration data model which is 680 easy to use. 682 o The concept of a 'superuser' type of account is supported, but 683 configuration such an account is beyond the scope of this 684 document. The server must be able to determine if a superuser 685 account is available, and if so, the actual user name for this 686 account. A session associated with the superuser account will 687 bypass all access control enforcement. 689 o A simple and familiar set of database permissions is used. 691 o Support for YANG security tagging (e.g., nacm:secure extension) 692 allows default security modes to automatically exclude sensitive 693 data. 695 o Separate default access modes for read, write, and execute 696 permissions. 698 o Access control rules are applied to configurable groups of users. 700 o The entire ACM can be disabled during operation, in order to debug 701 operational problems. 703 o Access control rules are simple to configure. 705 o The number of denied RPC operation requests and denied database 706 write requests can be monitored by the client. 708 o Simple unconstrained YANG instance identifiers are used to 709 configure access control rules for specific data nodes, or child 710 nodes within specific RPC input, RPC output, and notification 711 event type content. 713 5.1.2. External Dependencies 715 The NETCONF [RFC4741] protocol is used for all management purposes 716 within this document. The server must support the features 717 identified by the 'NETCONF-base' capability. It is expected that the 718 mandatory transport mapping NETCONF Over SSH [RFC4742] is also 719 supported by the server, and that the server has access to the user 720 name associated with each session. 722 The YANG Data Modeling Language [I-D.ietf-netmod-yang] is used to 723 define the NETCONF data models specified in this document. The YANG 724 instance-identifier data type can be used to configure data-node- 725 specific access control rules. 727 5.1.3. Message Processing Model 729 The following diagram shows the NETCONF message flow model, including 730 the points at which access control is applied, during NETCONF message 731 processing. 733 +-------------------------+ 734 | session | 735 | (username) | 736 +-------------------------+ 737 | ^ 738 V | 739 +--------------+ +---------------+ 740 | message | | message | 741 | dispatcher | | generator | 742 +--------------+ +---------------+ 743 | ^ ^ 744 V | | 745 +===========+ +-------------+ +----------------+ 746 | |---> | | | | 747 | acc. ctl | | generator | | generator | 748 +===========+ +-------------+ +----------------+ 749 | ^ ^ ^ 750 V +------+ | | 751 +-----------+ | +=============+ +================+ 752 | | | | | | | 753 | processor |-+ | acc. ctl | | access ctl | 754 +-----------+ +=============+ +================+ 755 | | ^ ^ 756 V +----------------+ | | 757 +===========+ | | | 758 | data node | | | | 759 | acc. ctl | -----------+ | | | 760 +===========+ | | | | 761 | | | | | 762 V V V | | 763 +---------------+ +-----------------+ 764 | configuration | ---> | server | 765 | database | | instrumentation | 766 | | <--- | | 767 +---------------+ +-----------------+ 769 Figure 2 771 The following high-level sequence of conceptual processing steps is 772 executed for each received message, if access control 773 enforcement is enabled: 775 o Access control is applied to all messages (except ) received by the server, individually, for each active 777 session, unless the user identity for the session is the 778 'superuser'. 780 o If the session is authorized to execute the specified RPC 781 operation, then processing continues, otherwise the request is 782 rejected with an 'access-denied' error. 784 o If the configuration database or conceptual state data is accessed 785 by the RPC operation, then the configuration access must be 786 authorized first. If the session is authorized to perform the 787 requested operation on the requested data, then processing 788 continues. 790 The following sequence of conceptual processing steps is executed for 791 each generated notification event, if access control enforcement is 792 enabled: 794 o Server instrumentation generates a conceptual notification, for a 795 particular subscription. 797 o The notification access control enforcer checks the notification 798 event type, and if it is one which the session is not authorized 799 to read, then the notification is dropped for that subscription. 801 5.2. Model Components 803 This section defines the conceptual components related to access 804 control model. 806 5.2.1. Users 808 A 'user' is the conceptual identity, which is associated with the 809 access permissions granted to a particular session. A user is 810 identified by a string which must be unique within the server. 812 The user name string is usually derived from the transport layer 813 during session establishment. A server is required to have an 814 authenticated user name for a session before requests will be 815 accepted. Otherwise all write requests must be rejected with an 816 'access-denied' error-tag value. If a read operation is not 817 authorized, then the requested data is silently dropped from the 818 reply. 820 The server MAY support a 'superuser' administrative user account, 821 which will bypass all access control enforcement. This is useful for 822 restricting initial access and repairing a broken access control 823 configuration. This account may be configurable to use a specific 824 user, or disabled completely. Some systems have factory-selected 825 superuser account names. There is no need to standardize the exact 826 user name for the superuser account. If no such account exists, then 827 all NETCONF access will be controlled by NACM. 829 5.2.2. Groups 831 Access to a specific NETCONF operation is granted to a session, 832 associated with a group, not a user. 834 A group is identified by its name. All group names must be unique 835 within the server. 837 A group member is identified by a user name string. 839 The same user may be configured in multiple groups. 841 The server should support the 3 default group identities defined in 842 this document (admin, monitor, guest), however these roles are just 843 unique identities, provided for operator convenience. There is no 844 standard behavior defined for each group identity. That is up to the 845 operator who configures the groups. 847 5.2.3. Sessions 849 A session is simply a NETCONF session, which is the entity which is 850 granted access to specific NETCONF operations. 852 A session is associated with a single user name for the lifetime of 853 the session. 855 5.2.4. Access Permissions 857 The access permissions are the NETCONF protocol specific set of 858 permissions that have been assigned to a particular session role or 859 group. 861 The same access permissions MUST stay in effect for the processing of 862 a particular message. 864 The server MUST use the access control rules in effect at the time 865 the message is processed. 867 The access control model treats RPC operation execution separately 868 from configuration database access and outgoing messages: 870 create: Permission to create conceptual server data. 872 read: Read access to conceptual server data, and 873 content. 875 update: Permission to modify existing conceptual server data. 877 delete: Permission to delete existing conceptual server data. 879 exec: Permission to invoke an RPC operation. 881 5.2.5. Global Enforcement Controls 883 A global on/off switch is provided to enable or disable all access 884 control enforcement. 886 An on/off switch is provided to enable or disable default access to 887 invoke RPC operations. 889 An on/off switch is provided to enable or disable default permission 890 to receive data in replies and notifications. 892 An on/off switch is provided to enable or disable default access to 893 alter configuration data. 895 5.2.6. Access Control Rules 897 There are 4 types of rules available in NACM: 899 module rule: Controls access for definitions in a specific module, 900 identified by its name. 902 RPC operation rule: Controls access for a specific RPC operation, 903 identified by its module and name. 905 data node rule: Controls access for a specific data node, identified 906 by its path location within the conceptual XML document for the 907 data node. 909 notification rule: Controls access for a specific notification event 910 type, identified by its module and name. 912 5.3. Access Control Enforcement Procedures 914 There are seven separate phases that must be addressed, four of which 915 are related to the NETCONF message processing model. In addition, 916 the initial start-up mode for a NETCONF server, session 917 establishment, and 'access-denied' error handling procedures must 918 also be considered. 920 5.3.1. Initial Operation 922 Upon the very first start-up of the NETCONF server, the access 923 control configuration will probably not be present. If not, a server 924 should not allow any write access to any session role except 925 'superuser' type of account in this state. 927 There is no requirement to enforce access control rules before or 928 while the non-volatile configuration data is processed and loaded 929 into the running configuration. 931 5.3.2. Session Establishment 933 The access control model applies specifically to the well-formed XML 934 content transferred between a client and a server, after session 935 establishment has been completed, and after the exchange has 936 been successfully completed. 938 A server should not include any sensitive information in any 939 elements within the exchange. 941 Once session establishment is completed, and a user identity has been 942 authenticated, a NETCONF server will enforce the access control 943 rules, based on the supplied user identity and the configuration data 944 stored on the server. 946 5.3.3. 'access-denied' Error Handling 948 The 'access-denied' error-tag is generated when the access control 949 system denies access to either a request to invoke an RPC operation 950 or a request to perform a particular operation on the configuration 951 database. 953 A server must not include any sensitive information in any elements within the response. 956 5.3.4. Incoming RPC Message Validation 958 The diagram below shows the basic conceptual structure of the access 959 control processing model for incoming NETCONF messages, within 960 a server. 962 NETCONF server 963 +------------+ 964 | XML | 965 | message | 966 | dispatcher | 967 +------------+ 968 | 969 | 970 V 971 +------------+ 972 | NC-base NS | 973 | | 974 +------------+ 975 | | | 976 | | +-------------------------+ 977 | +------------+ | 978 V V V 979 +-----------+ +---------------+ +------------+ 980 | acme NS | | NC-base NS | | NC-base NS | 981 | | | | | | 982 +-----------+ +---------------+ +------------+ 983 | | 984 | | 985 V V 986 +----------------------+ 987 | | 988 | configuration | 989 | database | 990 +----------------------+ 992 Figure 3 994 Access control begins with the message dispatcher. Only well-formed 995 XML messages should be processed by the server. 997 After the server validates the element, and determines the 998 namespace URI and the element name of the RPC operation being 999 requested, the RPC access control enforcer verifies that the session 1000 is authorized to invoke the RPC operation. 1002 The RPC operation is authorized by following these steps: 1004 1. If the parameter is set to 'false', then the RPC 1005 operation is permitted. 1007 2. If the session is associated with the 'superuser' account, then 1008 the RPC operation is permitted. 1010 3. If the requested operation is the NETCONF 1011 operation, then the RPC operation is permitted. 1013 4. Check all the entries for ones that contain a entry that matches the user name for the session making 1015 the request. 1017 5. If no groups are found: 1019 * If the requested RPC operation is associated with a YANG 1020 module advertised in the server capabilities, and the rpc 1021 statement contains a nacm:secure or nacm:very-secure 1022 extension, then the RPC operation is denied. 1024 * If the parameter is set to 'permit', then 1025 permit the RPC operation, otherwise deny the request. 1027 6. Check if there are any matching entries for the 1028 requested RPC operation. Any matching rules are processed in 1029 user-defined order, in case there are multiple 1030 entries for the requested RPC operation. 1032 7. If an entry is found, then check the 1033 bits field for the entry, otherwise continue. The 'exec' bit 1034 MUST be present in the bits field for an , so it is not used in this procedure. 1037 8. If the entry is considered a match, the the 'nacm- 1038 action' leaf is checked. If is equal to 'permit', then the RPC 1039 operation is permitted, otherwise it is denied. 1041 9. Check if there are any matching entries for the 1042 same module as the requested RPC operation. Any matching rules 1043 are processed in user-defined order, in case there are multiple 1044 entries for the module containing the requested 1045 RPC operation. 1047 10. If a entry is found, then check the bits field for the entry, otherwise continue. If the 1049 'exec' bit is present in the bits field then 1050 the RPC rule is considered a match. otherwise it is not 1051 considered to match the request. 1053 11. If the entry is considered a match, the the 'nacm- 1054 action' leaf is checked. If is equal to 'permit', then the RPC 1055 operation is permitted, otherwise it is denied. 1057 12. If the requested operation is identified an a nacm:secure or 1058 nacm:very-secure RPC operation, then the RPC operation is 1059 denied. 1061 13. If the parameter is set to 'permit', then permit 1062 the RPC operation, otherwise the RPC operation is denied. 1064 If the session is not authorized to invoke the RPC operation then an 1065 is generated with the following information: 1067 error-tag: access-denied 1069 error-path: /rpc/method-QName, where 'method-QName' is a qualified 1070 name identifying the actual RPC operation name. For example, 1071 '/rpc/edit-config' represents the operation in the 1072 NETCONF base namespace. 1074 If the configuration database is accessed, either directly or as a 1075 side effect of the RPC operation, then the server must intercept the 1076 operation and make sure the session is authorized to perform the 1077 requested operation on the specified data. 1079 5.3.5. Data Node Access Validation 1081 If a data node within a configuration database is accessed, or a 1082 conceptual non-configuration node is accessed, then the server must 1083 ensure that the client session is authorized to perform the requested 1084 operation create, read, update, or delete operation on the specified 1085 data node. 1087 The data node access request is authorized by following these steps: 1089 1. If the parameter is set to 'false', then the data 1090 node access request is permitted. 1092 2. If the session is associated with the 'superuser' account, then 1093 the data node access request is permitted. 1095 3. Check all the entries for ones that contain a entry that matches the user name for the session making 1097 the request. 1099 4. If no groups are found: 1101 * If the requested data node is associated with a YANG module 1102 advertised in the server capabilities, and the data 1103 definition statements (or any of its ancestors) contains a 1104 nacm:secure or nacm:very-secure extension, then the data node 1105 access request is denied. 1107 * For a read request, if the parameter is set to 1108 'permit', then permit the data node access request, otherwise 1109 deny the request. For a read operation, this means that the 1110 requested node is not included in the rpc-reply. 1112 * For a write request, if the parameter is set 1113 to 'permit', then permit the data node access request, 1114 otherwise deny the request. 1116 5. Check if there are any matching entries for the 1117 requested data node access request. Any matching rules are 1118 processed in user-defined order, in case there are multiple 1119 entries for the requested data node. 1121 6. If an entry is found, then check the bits field for the entry, otherwise continue. 1124 1. For a creation operation, if the 'create' bit is present in 1125 the bits field then the entry is considered 1126 to be a match. 1128 2. For a read operation, if the 'read' bit is present in the 1129 bits field, then the entry is considered to 1130 be a match. 1132 3. For an update (e.g., 'merge' or 'replace') operation, if the 1133 'update' bit is present in the bits field 1134 then the entry is considered to be a match. 1136 4. For a deletion (e.g., 'delete') operation, if the 'delete' 1137 bit is present in the bits field then the 1138 entry is considered to be a match. 1140 7. If the entry is considered a match, the the 'nacm- 1141 action' leaf is checked. If it is equal to 'permit', then the 1142 data operation is permitted, otherwise it is denied. For 'read' 1143 operations, 'denied' means the requested data is not returned in 1144 the reply. 1146 8. Check if there are any matching entries for the 1147 same module as the requested data node. Any matching rules are 1148 processed in user-defined order, in case there are multiple 1149 entries for the module containing the requested 1150 data node. 1152 9. If a entry is found, then check the bits field for the entry, otherwise continue. 1155 1. For a creation operation, if the 'create' bit is present in 1156 the bits field then the entry is considered 1157 to be a match. 1159 2. For a read operation, if the 'read' bit is present in the 1160 bits field, then the entry is considered to 1161 be a match. 1163 3. For an update (e.g., 'merge' or 'replace') operation, if the 1164 'update' bit is present in the bits field 1165 then the entry is considered to be a match. 1167 4. For a deletion (e.g., 'delete') operation, if the 'delete' 1168 bit is present in the bits field then the 1169 entry is considered to be a match. 1171 10. If the entry is considered a match, the the 'nacm- 1172 action' leaf is checked. If it is equal to 'permit', then the 1173 data operation is permitted, otherwise it is denied. For 'read' 1174 operations, 'denied' means the requested data is not returned in 1175 the reply. 1177 11. For a read request, if the requested data node is identified an 1178 a nacm:very-secure definition, then the requested data node is 1179 not included in the reply. 1181 12. For a write request, if the requested data node is identified an 1182 a nacm:secure or nacm:very-secure definition, then the data node 1183 access request is denied. 1185 13. For a read request, if the parameter is set to 1186 'permit', then include the requested data in the reply, 1187 otherwise do not inlcude the requested data in the reply. 1189 14. For a write request, if the parameter is set to 1190 'permit', then permit the data node access request, otherwise 1191 deny the request. 1193 5.3.6. Outgoing Authorization 1195 The message should be checked by the server to make sure 1196 no unauthorized data is contained within it. If so, the restricted 1197 data must be removed from the message before it is sent to the 1198 client. 1200 For RPC operations which do not access any data nodes, then any 1201 client authorized to invoke the RPC operation is also authorized to 1202 receive the for that RPC operation. 1204 5.3.7. Outgoing Authorization 1206 The message should be checked by the server to make 1207 sure no unauthorized data is contained within it. If so, the 1208 restricted data must be removed from the message before it is sent to 1209 the client. 1211 Configuration of access control rules specifically for descendent 1212 nodes of the notification event type element are outside the scope of 1213 this document. If the session is authorized to receive the 1214 notification event type, then it is also authorized to receive any 1215 data it contains. 1217 The following figure shows the conceptual message processing model 1218 for outgoing messages. 1220 NETCONF server 1221 +------------+ 1222 | XML | 1223 | message | 1224 | generator | 1225 +------------+ 1226 ^ 1227 | 1228 +----------------+ 1229 | | 1230 | generator | 1231 +----------------+ 1232 ^ 1233 | 1234 +=================+ 1235 | | 1236 | access control | 1237 | | 1238 +=================+ 1239 ^ 1240 | 1241 +------------------------+ 1242 | server instrumentation | 1243 +------------------------+ 1244 | ^ 1245 V | 1246 +----------------------+ 1247 | configuration | 1248 | database | 1249 +----------------------+ 1251 Figure 4 1253 The generation of a notification event for a specific subscription is 1254 authorized by following these steps: 1256 1. If the parameter is set to 'false', then the 1257 notification event is permitted. 1259 2. If the session is associated with the 'superuser' account, then 1260 the notification event is permitted. 1262 3. If the requested operation is the NETCONF or 1263 event type, then the notification event 1264 is permitted. 1266 4. Check all the entries for ones that contain a entry that matches the user name for the session that 1268 started the notification subscription. 1270 5. If no groups are found: 1272 * If the requested notification is associated with a YANG 1273 module advertised in the server capabilities, and the 1274 notification statement contains a nacm:secure or nacm:very- 1275 secure extension, then the notification event is dropped for 1276 the associated subscription. 1278 * If the parameter is set to 'permit', then 1279 permit the notification event, otherwise drop this event type 1280 for the associated subscription. 1282 6. Check if there are any matching entries for 1283 the specific notification event type being delivered to the 1284 subscription. Any matching rules are processed in user-defined 1285 order, in case there are multiple entries 1286 for the requested notification event type. 1288 7. If a entry is found, then check the 1289 bits field for the entry, otherwise continue. 1290 If the 'read' bit is present in the bits field 1291 then the notification event type is permitted, otherwise it is 1292 dropped for the associated subscription. 1294 8. Check if there are any matching entries for the 1295 same module as the notification event type. Any matching rules 1296 are processed in user-defined order, in case there are multiple 1297 entries for the module containing the notification 1298 event type. 1300 9. If a entry is found, then check the bits field for the entry, otherwise continue. If the 1302 'read' bit is present in the bits field then 1303 the notification event type is permitted, otherwise it is 1304 dropped for the associated subscription. 1306 10. If the requested event type is identified an a nacm:very-secure 1307 notification definition, then the notification event type is 1308 denied. 1310 11. If the parameter is set to 'permit', then permit 1311 the notification event type, otherwise it is dropped for the 1312 associated subscription. 1314 5.4. Data Model Definitions 1316 This section defines the semantics of the conceptual data structures 1317 found in the data model in Section 5.4. 1319 5.4.1. High Level Procedures 1321 There are some high level management procedures that an administrator 1322 needs to consider before using this access control model: 1324 1. Configure the global settings. 1326 2. Configure one or more user groups. 1328 3. Configure zero or more access control rules for specific modules. 1330 4. Configure zero or more access control rules for specific RPC 1331 operations. 1333 5. Configure zero or more access control rules for data node access. 1335 6. Configure zero or more access control rules for notification 1336 event type access. 1338 5.4.2. Data Organization 1340 The top-level element is called , and it is defined in the 1341 'nacm' module namespace. 1343 There are several data structures defined as child nodes of the 1344 element: 1346 leaf : On/off boolean switch to enable or disable 1347 access control enforcement. 1349 container : Configuration of the NETCONF server user 1350 authentication mechanisms. 1352 leaf : Enumeration to permit or deny default read 1353 access requests. 1355 leaf : Enumeration to permit or deny default write 1356 access requests. 1358 leaf : Enumeration to permit or deny default RPC 1359 operation execution requests. 1361 leaf : Read-only counter of the number of times the 1362 server has denied an RPC operation request, since the last reboot 1363 of the server. 1365 leaf : Read-only counter of the number of times 1366 the server has denied a data node write request, since the last 1367 reboot of the server. 1369 container : Configures the groups used within the access 1370 control system. 1372 list : A list of user names belonging to the same 1373 administrative group. 1375 container : Configures the access control rules used within 1376 the server. 1378 list : Configures the access control rules for a 1379 specific module. 1381 list : Configures the access control rules for RPC 1382 operation invocation. 1384 list : Configures the access control rules for 1385 configuration database access. 1387 list : Configures the access control rules for 1388 controlling delivery of events. 1390 5.4.3. YANG Module 1392 The following YANG module is provided to specify the normative 1393 NETCONF content that must by supported by the server. 1395 file="nacm@2010-06-29.yang" 1397 module nacm { 1399 namespace "file://draft-bierman-netconf-access-control-02.txt"; 1400 prefix "nacm"; 1402 import ietf-yang-types { 1403 prefix yang; 1404 } 1406 import ietf-inet-types { 1407 prefix inet; 1409 } 1411 organization 1412 "IETF"; 1414 contact 1415 "Andy Bierman 1416 Martin Bjorklund "; 1418 description 1419 "NETCONF Server Access Control Model"; 1421 revision 2010-06-29 { 1422 description 1423 "Initial version (work-in-progress)."; 1424 } 1426 /* 1427 * Extension statements 1428 */ 1430 extension secure { 1431 description 1432 "Used to indicate that the data model node 1433 represents a sensitive security system parameter. 1435 If present, the NETCONF server will only allow 1436 the designated 'superuser' to have write or execute 1437 default nacm-rights-type for the node. An explicit access 1438 control rule is required for all other users. 1440 The 'secure' extension may appear within a data, rpc, 1441 or notification node definition. It is ignored 1442 otherwise."; 1443 } 1445 extension very-secure { 1446 description 1447 "Used to indicate that the data model node 1448 controls a very sensitive security system parameter. 1450 If present, the NETCONF server will only allow 1451 the designated 'superuser' to have read, write, or execute 1452 default nacm-rights-type for the node. An explicit access 1453 control rule is required for all other users. 1455 The 'very-secure' extension may appear within a data, rpc, 1456 or notification node definition. It is ignored 1457 otherwise."; 1458 } 1460 /* 1461 * Features 1462 */ 1464 feature authentication { 1465 description 1466 "Indicates that the NETCONF server can be configured 1467 to do authentication of users."; 1468 } 1470 feature radius { 1471 if-feature authentication; 1472 description 1473 "Indicates that the NETCONF server can be 1474 configured to act as a NAS and authenticate users 1475 with RADIUS."; 1476 reference 1477 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 1478 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 1479 Authorization for Network Access Server (NAS) 1480 Management"; 1481 } 1483 feature local-users { 1484 if-feature authentication; 1485 description 1486 "Indicates that the NETCONF server supports 1487 local user authentication."; 1488 } 1490 /* 1491 * Identities 1492 */ 1494 identity authentication-method { 1495 description 1496 "Base identity for NETCONF authentication methods."; 1497 } 1499 identity radius { 1500 base authentication-method; 1501 description 1502 "Indicates NETCONF authentication using RADIUS."; 1503 reference 1504 "RFC 2865: Remote Authentication Dial In User Service (RADIUS) 1505 RFC 5607: Remote Authentication Dial-In User Service (RADIUS) 1506 Authorization for Network Access Server (NAS) 1507 Management"; 1508 } 1510 identity local-users { 1511 base authentication-method; 1512 description 1513 "Indicates password-based NETCONF authentication using locally 1514 configured users."; 1515 } 1517 /* 1518 * Derived types 1519 */ 1521 typedef nacm-user-name-type { 1522 type string { 1523 length "1..max"; 1524 } 1525 description 1526 "General Purpose User Name string."; 1527 } 1529 typedef nacm-matchall-string-type { 1530 type string { 1531 pattern "\*"; 1532 } 1533 description 1534 "The string containing a single asterisk '*' is used 1535 to conceptually represent all possible values 1536 for the particular leaf using this data type."; 1537 } 1539 typedef nacm-rights-type { 1540 type union { 1541 type nacm-matchall-string-type; 1543 type bits { 1544 bit create { 1545 description 1546 "Create access allowed to all specified data. 1547 Any protocol operation that creates a 1548 new instance of the specified data is a create 1549 operation."; 1550 } 1551 bit read { 1552 description 1553 "Read access allowed to all specified data. 1554 Any protocol operation or notification that 1555 returns data to an application is a read 1556 operation."; 1557 } 1558 bit update { 1559 description 1560 "Update access allowed to all specified data. 1561 Any protocol operation that alters an existing 1562 data node is an update operation."; 1563 } 1564 bit delete { 1565 description 1566 "Delete access allowed to all specified data. 1567 Any protocol operation that removes a database 1568 node instance is a delete operation."; 1569 } 1570 bit exec { 1571 description 1572 "Execution access to the specified RPC operation. 1573 Any RPC operation invocation is an exec operation."; 1574 } 1575 } 1576 } 1577 description 1578 "NETCONF Access Rights. 1579 The string '*' indicates that all possible access 1580 rights apply to the access rule. Otherwise, only 1581 the specific access rights represented by the bit names 1582 that are present apply to the access rule."; 1583 } 1585 typedef nacm-group-name-type { 1586 type string { 1587 length "1..max"; 1588 pattern "~\*[.*]"; 1589 } 1590 description 1591 "Name of administrative group that can be 1592 assigned to the user, and specified in 1593 an access control rule."; 1594 } 1596 typedef nacm-action-type { 1597 type enumeration { 1598 enum permit { 1599 description 1600 "Requested action is permitted."; 1602 } 1603 enum deny { 1604 description 1605 "Requested action is denied."; 1606 } 1607 } 1608 description 1609 "Action taken by the server when a particular 1610 rule matches."; 1611 } 1613 typedef schema-instance-identifier { 1614 type yang:xpath1.0; 1615 description 1616 "Path expression used to represent a special 1617 schema-instance identifier string. 1619 A schema-instance-identifier value is an 1620 unrestricted YANG instance-identifier expression. 1621 All the same rules as an instance-identifier apply 1622 except predicates for keys are optional. If a key 1623 predicate is missing, then the schema-instance-identifier 1624 represents all possible server instances for that key. 1626 This XPath expression is evaluated in the following context: 1628 o The set of namespace declarations are those in scope on 1629 the leaf element where this type is used. 1631 o The set of variable bindings contains one variable, 1632 'USER', which contains the name of user of the current 1633 session. 1635 o The function library is the core function library, but note 1636 that due to the syntax restrictions of an 1637 instance-identifier, no functions are allowed. 1639 o The context node is the root node in the data tree."; 1640 } 1642 typedef md5-crypt { 1643 type string { 1644 pattern "$0$.* | $1$[a-zA-Z0-9./]{2,8}$.*"; 1645 } 1646 description 1647 "The md5-crypt type is used to store a password hash based on the 1648 MD5 message digest algorithm. When a clear text value is set to 1649 a leaf of this type, the server calculates a MD5 password hash, 1650 and stores the result in the datastore. Thus, the password is 1651 never stored in clear text. 1653 When a leaf of this type is read, the stored password hash is 1654 returned. 1656 A value of this type matches one of the forms: 1658 $0$ 1659 $1$$ 1661 The '$0$' prefix signals that the value is clear text. When 1662 such a value is received by the server, an MD5 digest is 1663 calculated, and the string '$1$$' is prepended to the 1664 result, where is a random 2-8 characters long salt used 1665 to generate the digest. This value is stored in the 1666 configuration data store. 1668 If a value starting with '$1$$' is received, the server 1669 knows that the value already represents an MD5 digest, and 1670 stores it as is in the data store. 1672 When a server needs to verify a password given by a user, it 1673 finds the stored password hash string for that user, extracts 1674 the salt, and calculates the hash with the salt and given 1675 password as input. If the calculated hash value is the same as 1676 the stored value, the password given by the client is correct. 1678 The digest algorithm is the md5 crypt function used for 1679 encrypting passwords for various UNIX systems."; 1680 reference 1681 "RFC 1321: The MD5 Message-Digest Algorithm 1682 http://en.wikipedia.org/wiki/Crypt_(Unix)"; 1683 // FIXME: ref to wikipedia ok?? 1684 } 1686 container nacm { 1687 nacm:very-secure; 1689 presence 1690 "An empty nacm container indicates that the 1691 NACM service is running, and using 1692 all default parameters."; 1694 description 1695 "Parameters for NETCONF Access Control Model."; 1697 container authentication { 1698 nacm:very-secure; 1699 if-feature authentication; 1701 description 1702 "The authentication configuration for the 1703 NETCONF server."; 1705 leaf-list user-authentication-order { 1706 type identityref { 1707 base authentication-method; 1708 } 1709 must '(. = "nacm:radius" and ../radius/server) or' 1710 + '(. != "nacm:radius")' { 1711 error-message 1712 "When 'radius' is used, a radius server 1713 must be configured."; 1714 } 1715 ordered-by user; 1717 description 1718 "When the NETCONF server authenticates a user with 1719 a password, it tries the authentication methods in this 1720 leaf-list in order. If authentication with one method 1721 fails, the next method is used. If no method succeeds, 1722 the user is denied access. 1724 If the 'radius' feature is advertised by the NETCONF 1725 server, the 'radius' identity can be added to this 1726 list. 1728 If the 'local-users' feature is advertised by the 1729 NETCONF server, the 'local-users' identity can be 1730 added to this list."; 1731 } 1733 container radius { 1734 if-feature radius; 1736 description 1737 "The radius configuration for the NETCONF server."; 1739 list server { 1740 key address; 1742 description 1743 "The radius server configuration used by 1744 the NETCONF server."; 1746 leaf address { 1747 type inet:host; 1748 description 1749 "The address of the radius server."; 1750 } 1751 leaf port { 1752 type inet:port-number; 1753 default "1812"; 1754 description 1755 "The port number of the radius server."; 1756 } 1757 leaf shared-secret { 1758 type string; // FIXME 1759 /* 1760 We're using a special type aes-cfb-128-encrypted-string which works 1761 like the md5-crypt string, but encrypts the clear text value using a 1762 pre-provisioned password (not part of the config db!). 1764 We use $0$ for cleartext and $4$ for the encrypted value. 1765 (we also have a des-version which uses $3$). 1767 But I was thinking that maybe we could define a type for encrypted 1768 values without specifying the encryption algorithm, just specifying 1769 the format. $0$ | $x$, and how it is 1770 encrypted is implementation specific. 1772 One alternative is to store this shared secret in clear text. It is 1773 transmitted over a secure transport, and marked as very-secure. (The 1774 same argument could be made for user passwords, but these are 1775 personal and not even root should be able to read my passwd in clear 1776 text, so it makes more sense to keep them hidden.) 1777 */ 1778 description 1779 "The shared secret which is known to both the RADIUS 1780 client and server."; 1781 reference 1782 "RFC 2865: Remote Authentication Dial In User Service"; 1783 } 1784 /* 1785 How about configuration of number of retransmits 1786 and timeout? 1787 */ 1788 } 1789 } 1791 list user { 1792 if-feature local-users; 1793 key name; 1794 description 1795 "The list of local users configured on this device."; 1797 leaf name { 1798 type nacm-user-name-type; 1799 description 1800 "The user name string identifying this entry."; 1801 } 1802 leaf password { 1803 type md5-crypt; 1804 description 1805 "The password for this entry."; 1806 } 1807 leaf ssh-dsa { 1808 type binary; 1809 description 1810 "The public DSA key for this entry."; 1811 } 1812 leaf ssh-rsa { 1813 type binary; 1814 description 1815 "The public RSA key for this entry."; 1816 } 1817 } 1818 } 1820 leaf enable-nacm { 1821 type boolean; 1822 default true; 1823 description 1824 "Enable or disable all NETCONF access control 1825 enforcement. If 'true', then enforcement 1826 is enabled. If 'false', then enforcement 1827 is disabled."; 1828 } 1830 leaf read-default { 1831 type nacm-action-type; 1832 default "permit"; 1833 description 1834 "Controls whether read access is granted if 1835 no appropriate rule is found for a 1836 particular read request."; 1837 } 1839 leaf write-default { 1840 type nacm-action-type; 1841 default "deny"; 1842 description 1843 "Controls whether create, update, or delete access 1844 is granted if no appropriate rule is found for a 1845 particular write request."; 1846 } 1848 leaf exec-default { 1849 type nacm-action-type; 1850 default "permit"; 1851 description 1852 "Controls whether exec access is granted if no appropriate 1853 rule is found for a particular RPC operation request."; 1854 } 1856 leaf denied-rpcs { 1857 type yang:zero-based-counter32; 1858 config false; 1859 mandatory true; 1860 description 1861 "Number of times an RPC operation request was denied 1862 since the server last restarted."; 1863 } 1865 leaf denied-data-writes { 1866 type yang:zero-based-counter32; 1867 config false; 1868 mandatory true; 1869 description 1870 "Number of times a request to alter a data node 1871 was denied, since the server last restarted."; 1872 } 1874 container groups { 1875 list group { 1876 key name; 1878 description 1879 "One NACM Group Entry."; 1881 leaf name { 1882 type nacm-group-name-type; 1883 description 1884 "Group name associated with this entry."; 1885 } 1887 leaf-list user-name { 1888 type nacm-user-name-type; 1889 description 1890 "Each entry identifies the user name of 1891 a member of the group associated with 1892 this entry."; 1893 } 1894 } 1895 } 1897 container rules { 1898 description 1899 "NETCONF Access Control Rules."; 1901 grouping common-rule-parms { 1902 leaf rule-name { 1903 type string { 1904 length "1..256"; 1905 } 1906 description 1907 "Arbitrary name assigned to the 1908 access control rule."; 1909 } 1911 leaf allowed-rights { 1912 type nacm-rights-type; 1913 description 1914 "List of access rights granted to 1915 specified administrative groups for the 1916 content specified by the associated path."; 1917 } 1919 leaf-list allowed-group { 1920 type union { 1921 type nacm-matchall-string-type; 1922 type nacm-group-name-type; 1923 } 1924 min-elements 1; 1925 description 1926 "List of administrative groups which will be 1927 assigned the associated access rights 1928 for the content specified by the associated path. 1930 The string '*' indicates that all configured 1931 administrative groups apply to the entry."; 1932 } 1934 leaf nacm-action { 1935 type nacm-action-type; 1936 mandatory true; 1937 description 1938 "The access control action associated with the 1939 rule. If a rule is determined to match a 1940 particular request, then this object is used 1941 to determine whether to permit or deny the 1942 request."; 1943 } 1945 leaf comment { 1946 type string { 1947 length "1..4095"; 1948 } 1949 description 1950 "A textual description of the access rule."; 1951 } 1952 } 1954 list module-rule { 1955 key "module-name rule-name"; 1956 ordered-by user; 1958 description 1959 "One Module Access Rule. 1961 Rules are processed in user-defined order. A module rule 1962 is considered a match if the XML namespace for the 1963 specified module name matches the XML namespace used 1964 within a NETCONF PDU, and the administrative group 1965 associated with the requesting session is specified in the 1966 'allowed-group' leaf-list, and the requested operation 1967 is included in the 'allowed-rights' leaf."; 1969 leaf module-name { 1970 type string; 1971 description 1972 "Name of the module associated with this rule."; 1973 } 1975 uses common-rule-parms { 1976 refine allowed-rights { 1977 mandatory true; 1978 } 1979 } 1980 } 1982 list rpc-rule { 1983 key "module-name rpc-name rule-name"; 1984 ordered-by user; 1985 description 1986 "One RPC Operation Access Rule. 1988 Rules are processed in user-defined order. An RPC rule is 1989 considered a match if the module name of the requested RPC 1990 operation matches 'module-name', the requested RPC 1991 operation matches 'rpc-name', and an administrative group 1992 associated with the session user is listed in the 1993 'allowed-group' leaf-list. The 'allowed-rights' leaf 1994 is ignored by the server if it is present. 1995 Only the 'exec' bit can possibly cause 1996 a match for an RPC rule."; 1998 leaf module-name { 1999 type string; 2000 description 2001 "Name of the module defining this RPC operation."; 2002 } 2004 leaf rpc-name { 2005 type string; 2006 description 2007 "Name of the RPC operation."; 2008 } 2010 uses common-rule-parms; 2011 } 2013 list data-rule { 2014 key "rule-name"; 2015 ordered-by user; 2017 description 2018 "One Data Access Control Rule. 2020 Rules are processed in user-defined order. A data rule is 2021 considered to match when the path expression identifies 2022 the same node that is being accessed in the NETCONF 2023 database, and the administrative group associated with the 2024 session is identified in the 'allowed-group' leaf-list, 2025 and the requested operation is included in the 2026 'allowed-rights' leaf."; 2028 leaf path { 2029 type schema-instance-identifier; 2030 mandatory true; 2031 description 2032 "Schema Instance Identifier associated with the data node 2033 controlled by this rule. 2035 Configuration data or state data instance identifiers 2036 start with a top-level data node. A complete instance 2037 identifier is required for this type of path value. 2039 The special value '/' refers to all possible database 2040 contents."; 2041 } 2043 uses common-rule-parms { 2044 refine allowed-rights { 2045 mandatory true; 2046 } 2047 } 2048 } 2050 list notification-rule { 2051 key "module-name 2052 notification-name 2053 rule-name"; 2054 ordered-by user; 2056 description 2057 "One Notification Access Rule. 2059 A notification is considered a match if the module name of 2060 the requested event type matches 2061 'module-name', the requested event type 2062 matches the 'notification-name', and the administrative 2063 group associated with the requesting session is listed in 2064 the 'allowed-group' leaf-list. If the 'allowed-rights' 2065 leaf is present, it is ignored by the server. 2066 Only the 'read' bit can possibly cause 2067 a match for a notification rule."; 2069 leaf module-name { 2070 type string; 2071 description 2072 "Name of the module defining this 2073 notification event type."; 2074 } 2076 leaf notification-name { 2077 type string; 2078 description 2079 "Name of the notification event."; 2080 } 2081 uses common-rule-parms; 2082 } 2083 } 2084 } 2085 } 2087 2089 Figure 5 2091 5.5. IANA Considerations 2093 There are two actions that are requested of IANA: 2095 1. register data model schema namespace URI (TBD) 2097 2. register data model name ('nacm') 2099 5.6. Security Considerations 2101 This entire document discusses access control requirements and 2102 mechanisms for restricting NETCONF protocol behavior within a given 2103 session. 2105 Configuration of the access control system is highly sensitive to 2106 system security. A server may choose not to allow any user 2107 configuration to some portions of it, such as the global security 2108 level, or the groups which allowed access to system resources. 2110 This document incorporates the optional use of a 'superuser' account, 2111 which can be used to bypass access control enforcement. It is 2112 suggested that the 'root' account not be used for NETCONF over SSH 2113 servers, because 'root' SSH logins should be disabled in the SSH 2114 server. 2116 If the server chooses to allow user configuration of the access 2117 control system, then only sessions using the 'superuser' 2118 administrative user should be allowed to have write access to the 2119 data model. 2121 If the server chooses to allow user retrieval of the access control 2122 system configuration, then only sessions using the 'superuser' 2123 administrative user should be allowed to have read access to the data 2124 model. 2126 There is a risk that invocation of non-standard RPC operations will 2127 have undocumented side effects. An administrator should construct 2128 access control rules such that the configuration database is 2129 protected from such side effects. Also, such RPC operations should 2130 never be invoked by a session using the 'superuser' administrative 2131 user. 2133 There is a risk that non-standard RPC operations, or even the 2134 standard operation, may return data which 'aliases' or 'copies' 2135 sensitive data from a different data object. In this case, the 2136 namespace and/or the element name will not match the values for the 2137 sensitive data, which is then fully or partially copied into a 2138 different namespace and/or element. An administrator should avoid 2139 using data models which use this practice. 2141 An administrator should restrict write access to all configurable 2142 objects within this data model. It is suggested that only sessions 2143 using the 'superuser' administrative role be permitted to configure 2144 the data model defined in this document. 2146 If write access is allowed for configuration of access control rules, 2147 then care must be taken not to disrupt the access control 2148 enforcement. 2150 An administrator should restrict read access to the following objects 2151 within this data model, which reveal access control configuration 2152 which could be considered sensitive. 2154 o enable-nacm 2156 o read-default 2158 o write-default 2160 o exec-default 2162 o groups 2164 o rules 2166 6. Normative References 2168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2169 Requirement Levels", BCP 14, RFC 2119, March 1997. 2171 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2172 "Remote Authentication Dial In User Service (RADIUS)", 2173 RFC 2865, June 2000. 2175 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2176 Authentication Protocol", RFC 4252, January 2006. 2178 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2179 Transport Layer Protocol", RFC 4253, January 2006. 2181 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 2182 December 2006. 2184 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 2185 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 2186 December 2006. 2188 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2189 Notifications", RFC 5277, July 2008. 2191 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 2192 User Service (RADIUS) Authorization for Network Access 2193 Server (NAS) Management", RFC 5607, July 2009. 2195 [W3C.REC-xml] 2196 Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 2197 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- 2198 xml, October 2000, . 2200 [I-D.ietf-netmod-yang] 2201 Bjorklund, M., "YANG - A data modeling language for the 2202 Network Configuration Protocol (NETCONF)", 2203 draft-ietf-netmod-yang-13 (work in progress), June 2010. 2205 [I-D.ietf-netmod-yang-types] 2206 Schoenwaelder, J., "Common YANG Data Types", 2207 draft-ietf-netmod-yang-types-09 (work in progress), 2208 April 2010. 2210 Appendix A. Usage Examples 2212 The following XML snippets are provided as examples only, to 2213 demonstrate how NACM can be configured to perform some access control 2214 tasks. 2216 A.1. Example 2218 There must be at least one entry in order for any of the 2219 access control rules to be useful. 2221 The following XML shows arbitrary groups, and is not intended to 2222 represent any particular use-case. 2224 2225 2226 2227 admin 2228 admin 2229 andy 2230 2232 2233 monitor 2234 wilma 2235 bam-bam 2236 2238 2239 guest 2240 guest 2241 guest@example.com 2242 2243 2244 2246 This example shows 3 groups: 2248 1. The nacm:admin group contains 2 users named 'admin' and 'andy'. 2250 2. The nacm:monitor group contains 2 users named 'wilma' and 'bam- 2251 bam'. 2253 3. The nacm:guest group contains 2 users named 'guest' and 2254 'guest@example.com'. 2256 A.2. Example 2258 Module rules are used to control access to all the content defined in 2259 a specific module. These rules are checked after none of the 2260 specific rules (i.e., rpc-rule, data-rule, or notification-rule) 2261 matched the current access request. 2263 2264 2265 2266 ietf-netconf-monitoring 2267 mod-1 2268 * 2269 guest 2270 deny 2271 2272 Do not allow guests any access to the netconf 2273 monitoring information. 2274 2275 2277 2278 ietf-netconf-monitoring 2279 mod-2 2280 read 2281 monitor 2282 permit 2283 2284 Allow the monitor group read access to the netconf 2285 monitoring information. 2286 2287 2289 2290 * 2291 mod-3 2292 exec 2293 monitor 2294 permit 2295 2296 Allow the monitor group to invoke any of the 2297 supported server operations. 2298 2299 2300 2301 * 2302 mod-4 2303 * 2304 admin 2305 permit 2306 2307 Allow the admin group complete access to all 2308 operations and data. 2309 2310 2312 2313 2315 This example shows 4 module rules: 2317 mod-1: This rule prevents the guest group from reading any 2318 monitoring information in the ietf-netconf-monitoring YANG module. 2320 mod-2: This rule allows the monitor group to read the ietf-netconf- 2321 monitoring YANG module. 2323 mod-3: This rule allows the monitor group to invoke any RPC 2324 operation supported by the server. 2326 mod-4: This rule allows the admin group complete access to all 2327 content in the server. No subsequent rule will match for the 2328 admin group, because of this module rule. 2330 A.3. Example 2332 RPC rules are used to control access to a specific RPC operation. 2334 2335 2336 2337 ietf-netconf 2338 kill-session 2339 rpc-1 2340 monitor 2341 guest 2342 deny 2343 2344 Do not allow the monitor or guest group 2345 to kill another session. 2346 2347 2349 2350 ietf-netconf 2351 delete-config 2352 rpc-2 2353 monitor 2354 guest 2355 deny 2356 2357 Do not allow monitor or guest group 2358 to delete any configurations. 2359 2360 2362 2363 ietf-netconf 2364 edit-config 2365 rpc-3 2366 monitor 2367 permit 2368 2369 Allow the monitor group to edit the configuration. 2370 2371 2372 2373 2375 This example shows 3 RPC operation rules: 2377 rpc-1: This rule prevents the monitor or guest groups from invoking 2378 the NETCONF RPC operation. 2380 rpc-2: This rule prevents the monitor or guest groups from invoking 2381 the NETCONF RPC operation. 2383 rpc-3: This rule allows the monitor group to invoke the NETCONF 2384 RPC operation. This rule will have no real affect 2385 unless the 'exec-default' leaf is set to 'deny'. 2387 A.4. Example 2389 Data rules are used to control access to specific (config and non- 2390 config) data nodes within the NETCONF content provided by the server. 2392 2393 2394 2395 data-1 2396 /nacm 2397 * 2398 guest 2399 deny 2400 2401 Deny the guest group any access to the /nacm data. 2402 2403 2405 2406 data-acme-config 2407 2408 /acme:acme-netconf/acme:config-parameters 2409 2410 read create update delete 2411 monitor 2412 permit 2413 2414 Allow the monitor group complete access to the acme 2415 netconf configuration parameters. Showing long form 2416 of 'allowed-rights' instead of shorthand. 2417 2418 2420 2421 dummy-itf 2422 2423 /acme:interfaces/acme:interface[acme:name='dummy'] 2425 2426 read update 2427 monitor 2428 guest 2429 permit 2430 2431 Allow the monitor and guest groups read 2432 and update access to the dummy interface. 2433 2434 2436 2437 admin-itf 2438 2439 /acme:interfaces/acme:interface 2440 2441 * 2442 admin 2443 permit 2444 2445 Allow admin full access to all acme interfaces. 2446 This is an example of an unreachable rule, 2447 because the admin group already has full access 2448 to all modules (see rule 'mod-4'). 2449 All 'module-rule' entries will be checked 2450 before this 'data-rule' entry is checked. 2451 2452 2453 2454 2456 This example shows 4 data rules: 2458 data-1: This rule denies the guest group any access to the 2459 sub-tree. Note that the default namespace is only applicable 2460 because this sub-tree is defined in the same namespace as the 2461 element. 2463 data-acme-config: This rule gives the monitor group read-write 2464 access to the acme . 2466 dummy-itf: This rule gives the monitor and guest groups read-update 2467 access to the acme . entry named 'dummy'. This entry 2468 cannot be created or deleted by these groups, just altered. 2470 admin-itf: This rule gives the admin group read-write access to all 2471 acme . entries. This is an example of an unreachable 2472 rule because the 'mod-3' rule already gives the admin group full 2473 access to this data. 2475 A.5. Example 2477 Notification rules are used to control access to a specific 2478 notification event type. 2480 2481 2482 2483 acme-system 2484 sys-config-change 2485 notif-1 2486 monitor 2487 guest 2488 deny 2489 2490 Do not allow the guest or monitor groups 2491 to receive config change events. 2492 2493 2494 2495 2497 This example shows 1 notification rule: 2499 notif-1: This rule prevents the monitor or guest groups from 2500 receiving the acme event type. 2502 Appendix B. Open Issues 2504 1. Do modules need to be identified by their XML namespace URI, or 2505 is the module name good enough? 2507 2. Are any more wildcard mechanisms needed to specify the scope of 2508 an access control rule? 2510 3. Should regular expressions (module='foo-*') be allowed in schema- 2511 instance-identifier strings? 2513 4. Should XPath be allowed for specifying access control rules for 2514 data nodes? 2516 5. Are any 'access-denied' notifications needed? 2518 6. Should data rules support nodes that would not be eligible for 2519 retrieval with the operation? If so, should schema nodes 2520 such as rpc 'input' or 'output' be in the path expression? How 2521 would notification content be identified? 2523 7. Do any external access control models need to be supported 2524 somehow? For example, should the configuration be 2525 optionally read-only, so it can just mirror the internal 2526 (external or proprietary) group configuration? 2528 8. Should the nacm:secure and nacm:very-secure extensions be 2529 optional to support, via a YANG feature? 2531 9. Should the default access levels (e.g., read-default) be more 2532 restrictive by default? Shiuld these defaults be a vendor 2533 decision? An operator decision? It is important that the server 2534 be able to install a factory default container if needed. 2536 Authors' Addresses 2538 Andy Bierman 2539 InterWorking Labs 2540 Scotts Valley, CA 2541 USA 2543 Email: andyb@iwl.com 2545 Martin Bjorklund 2546 Tail-f Systems 2548 Email: mbj@tail-f.com