idnits 2.17.1 draft-seitz-netconf-xacml-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1594. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2007) is 6020 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 403 ** Downref: Normative reference to an Informational RFC: RFC 2904 ** Obsolete normative reference: RFC 4741 (Obsoleted by RFC 6241) -- Possible downref: Non-RFC (?) normative reference: ref. 'XACML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPath' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Seitz 3 Internet-Draft SICS, Swedish Institute of 4 Intended status: Standards Track Computer Science AB 5 Expires: April 6, 2008 E. Rissanen 6 Axiomatics AB 7 October 4, 2007 9 NETCONF access control profile for XACML 10 draft-seitz-netconf-xacml-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 6, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The NETCONF remote network configuration protocol currently lacks an 44 access control model. The need for such a model has been recognised 45 within the NETCONF working group. The eXtended Access Control Markup 46 Language (XACML) is an XML-based access control standard, with 47 widespread acceptance from the industry and good open-source support. 48 This document proposes a profile that defines how to use XACML to 49 provide fine-grain access control for NETCONF commands. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. XACML overview . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. NETCONF overview . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Policy and Request profile for XACML . . . . . . . . . . . . . 8 58 5.1. Abbreviations and namespaces . . . . . . . . . . . . . . . 8 59 5.2. New XACML functions, attributes and data-types . . . . . . 8 60 5.3. get and get-config RPC . . . . . . . . . . . . . . . . . . 10 61 5.4. edit-config RPC . . . . . . . . . . . . . . . . . . . . . 13 62 5.5. copy-config and delete-config RPC . . . . . . . . . . . . 16 63 5.6. lock and unlock RPC . . . . . . . . . . . . . . . . . . . 19 64 5.7. kill-session RPC . . . . . . . . . . . . . . . . . . . . . 21 65 5.8. close-session RPC . . . . . . . . . . . . . . . . . . . . 22 66 5.9. commit and discard-changes RPC . . . . . . . . . . . . . . 23 67 5.10. validate RPC . . . . . . . . . . . . . . . . . . . . . . . 24 68 6. Practical consequences for NETCONF implementations . . . . . . 26 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 73 Appendix A. Abbreviations . . . . . . . . . . . . . . . . . . . . 29 74 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 30 75 B.1. Get-config example . . . . . . . . . . . . . . . . . . . . 30 76 B.2. edit-config example . . . . . . . . . . . . . . . . . . . 35 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 78 Intellectual Property and Copyright Statements . . . . . . . . . . 42 80 1. Requirements notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Introduction 88 The NETCONF protocol rfc [RFC4741] specifies in its Security 89 Considerations (section 9) that "This document does not specify an 90 authorization scheme, ... Implementors SHOULD provide a 91 comprehensive authorization scheme with NETCONF". In this document a 92 profile is defined and explained that allows to use the eXtended 93 Access Control Markup Language [XACML] as authorization scheme for 94 NETCONF commands. The reasons why the use of XACML is suggested are 95 the following: 97 o XACML is an open standard that has been developed by an industry 98 consortium. 100 o XACML is an XML [XML] based approach, that is well adapted to the 101 authorization challenges encountered within NETCONF. 103 o XACML is widely accepted and used in a number of commercial 104 products [XACMLProducts]. 106 o Open-source implementations of the XACML standard are readily 107 available. 109 3. XACML overview 111 This section gives a short overview of what XACML is and how it 112 works. We only describe the parts of XACML that are needed in this 113 draft, therefore some descriptions may not reflect the full 114 functionality of the corresponding XACML element. Some familiarity 115 with the terms from [RFC2904] (e.g. PDP, PEP) is expected from the 116 reader. The references also include a more detailed introduction 117 [XACMLIntro]. 119 The XACML standard defines two things: 121 o A XML schema defining a syntax for requests, access control 122 policies and responses. 124 o A processing model that specifies how a request shall be evaluated 125 by a PDP against a set of policies in order to generate a 126 response. 128 A request is a collection of attributes typically describing the 129 requesting subject, the requested resource and the action that the 130 subject wishes to perform on the resource. An attribute can for 131 example be a role of the user or a resource group-id. 133 A policy consists of a target and one or more rules generating an 134 effect. The target describes for which request the policy applies, 135 in terms of conditions on a set of attributes. During evaluation 136 these attributes are fetched from the request and from external 137 information sources (PIPs) available to the PDP. If a policy 138 applies, its effect will either be PERMIT or DENY. 140 An example policy target is shown here: 142 01 143 02 144 03 145 04 146 05 print 147 06 150 09 151 10 ... 152 11 153 12 ... 154 13 155 14 ... 156 15 157 The Target consists of one or more AnyOf sections which must all be 158 fulfilled in order for the policy to apply. Within the AnyOf 159 section, one of the AllOfs must apply. Within a AllOf, all of the 160 Matches must apply. A Match specifies a matching function (which 161 must have a boolean result), and the function parameters, which can 162 either be static AttributeValue (as in line 04) or a value fetched 163 externally from the request of a PIP (as in line 05-07). The 164 AttributeDesignator (lines 05-07) specifies which external value(s) 165 to fetch by giving a Category, an Identifier and a DataType. If 166 several values are returned, only one needs to satisfy the Match 167 function. 169 4. NETCONF overview 171 The NETCONF configuration protocol describes a set of operations that 172 read or write configuration data on a network device. These 173 operations are transferred to the device by the means of remote 174 procedure calls (RPCs) encoded in XML. The different protocol 175 operations are: 177 o allows to get specific parts of a specific 178 configuration. 180 o allows to edit specific parts of a specific 181 configuration. 183 o allows to overwrite a specific configuration with a 184 new one from a specific source. 186 o allows to delete a specific configuration. 188 o allows to lock a specific configuration for editing. 190 o allows to unlock a specific configuration. 192 o allow to get specific parts from the "running" 193 configuration. 195 o allows to close your own session. 197 o allows to kill someone else's session. 199 For a more specific description of the NETCONF protocol please refer 200 to [RFC4741]. 202 The present document defines an access control model for these 203 operations and for the extensions defined in the standard. 205 5. Policy and Request profile for XACML 207 The goal of this section is to define how a PEP SHOULD generate a 208 XACML request from a RPC carrying a NETCONF operation. The response 209 to this request determines whether the RPC is processed or discarded. 210 Furthermore this profile defines how policies corresponding to 211 permissions about a specific NETCONF operation on specific data 212 SHOULD be formulated. A strong familiarity with the latest XACML 213 syntax is required to fully appreciate this section. 215 The part of XACML authorisation that deals with the subjects (e.g. in 216 terms of user groups or roles) is out of scope for this profile, 217 since it is not in any way specific to the NETCONF protocol. Thus 218 all the following definitions omit the subject parts of both requests 219 and policies (indicated by "..."). This part can be defined 220 independently from this profile. 222 5.1. Abbreviations and namespaces 224 Since XML in general, and especially the XACML syntax, are quite 225 verbose we have defined a set of abbreviations, that can be found in 226 section Appendix A. Furthermore we use the term 'Attribute' 227 exclusively for XACML attributes. If we refer to attributes of XML 228 elements we specify this by adding the prefix 'XML' as in 'XML- 229 attribute'. 231 In order to clearly identify new XACML functions, attributes, and 232 data-types defined specifically for this profile they SHALL have the 233 identifier-prefix "xacml-netconf". Thus the following identifiers- 234 prefixes SHALL be used: 236 o Functions: "xacml-netconf:function:" 238 o Attributes: "xacml-netconf:attribute:" 240 o Data-types: "xacml-netconf:data-type:" 242 5.2. New XACML functions, attributes and data-types 244 This section defines the new functions, attributes and data-types for 245 XACML introduced by this profile. 247 o XACML function: Id="xacml-netconf:function:xpath-node-match" 248 Parameter 1 data-type: &xpath; 249 Parameter 2 data-type: &xpath; 251 The basic idea of this function is to check whether a xml-node in 252 a xml-document is matched by a certain XPath [XPath]. Due to the 253 difficulty of encoding a xml-node in its document context, we use 254 a second XPath to point to that xml-node in the document. 255 This function works in two steps. First it evaluates the second 256 xpath (representing the xml-node) against the Content element of 257 the Request. This XPath must match a single xml-node only 258 (otherwise an error is returned). 259 In the second step, the first XPath expression is evaluated 260 against the same Content. If the resulting set of xml-nodes 261 contains the xml-node that results from the first step or one of 262 its ancestors, the value of this function is true, otherwise it is 263 false. 264 The following example shall illustrate how this function works: 265 Given the function parameters: 266 /top/interfaces[name="Ethernet"]/interface and 267 /top/interfaces[name="Ethernet"]/interface 268 as well as the content XML document: 270 01 271 02 272 03 Ethernet 273 04 274 05 Ethernet0/0 275 06 1500 276 07 277 08 278 09 Ethernet1/1 279 10 3000 280 11 281 12 282 13 Ethernet2/2 283 14 1000 284 15 285 16 286 17 287 18 WLAN 288 19 289 20 DHCP0/0 290 21 291 22 292 23 294 We get the following evaluation: 295 1. The second xpath points out the xml-node at line 09. 296 2. The first xpath points out the xml-nodes 03, 07 and 11. 297 Since xml-node 07 is an ancestor of xml-node 09 the function 298 evaluates to true. 300 o XACML attribute: Id="xacml-netconf:attribute:rpc-target" 301 Category=&Resource; 302 data-type=&string; 304 This attribute indicates which data store the operation is 305 targeting. In the case of the copy-config command, this is the 306 destination data store. For the lock/unlock commands this is the 307 target data store. An example value would be "running". 309 o XACML attribute: Id="xacml-netconf:attribute:rpc-source" 310 Category=&Resource; 311 data-type=&string; or data-type=&AnyURI; 313 This attribute indicates the source for the operation. In the 314 case of the copy-config command, this is the source data store or 315 an URL. An example value would be "candidate". 317 o XACML data-type: Id="xacml-netconf:data-type:xpath-expression" 319 This data-type is a XPath. The data-type also encodes necessary 320 namespace information, if the XPath is to be used on a namespace 321 aware document. The encoding is an XML-tag with the name of 322 "xpath" containing zero or more attributes, each defining a 323 namespace prefix to namespace URI matching for use with this 324 XPath. 325 An example xpath expression would look like this: 327 01 328 02 329 03 //ns1:top/ns1:interfaces[ns1:name="Ethernet"] 330 04 331 05 333 5.3. get and get-config RPC 335 The get/get-config RPCs get a special treatment, because it was 336 deemed that the whole RPC shouldn't fail just because the the user is 337 not authorised to read parts of the result. Instead the desired 338 behaviour in such a case is to prune the results that are not covered 339 by the users rights. Therefore it is RECOMMENDED to perform access 340 control on the result of a get/get-config RPC instead of on the RPC 341 itself, so that the unauthorised elements can be filtered out and 342 only the authorised ones remain. 344 Requests for get/get-config RPCs SHALL be formed as follows: As a 345 first step, calculate which xml-nodes of the data model are the 346 results of the RPC. For each xml-node in the result, run an XACML 347 request. The request contains 348 1. The whole result document under the xml-node. 350 2. A "&Resource;" category Attribute with AttributeId=&resource-id; 351 having the AttributeValue of DataType="&xpath;" which contains an 352 XPath that uniquely identifies the xml-node in question. 354 3. Another &Resource; category Attribute with AttributeId="xacml- 355 netconf:attribute:rpc-source" and the AttributeValue with 356 DataType="&string;" that identifies the data-model this RPC uses 357 as source (i.e. "running", "startup" or "candidate") 358 corresponding to the RPC source. This SHALL always have a value 359 of "running" for "get" RPCs. 361 4. An "Action" category Attribute with AttributeId="action-id" and 362 the AttributeValue "read" with DataType="&string;". 364 Each xml-node that is permitted by the corresponding request is 365 included in the result together with its ancestors and descendants. 366 Furthermore the requests for its descendants are skipped. Those xml- 367 nodes that are not permitted are not included. 369 These multiple XACML requests can be executed very efficiently if the 370 PDP is running locally on the network element, preferably in the same 371 process as the NETCONF agent. Such an architecture would mean that 372 no new XML documents get generated and no network communication needs 373 to be done for those repeated requests. 375 For security reasons it is advisable not to report that parts of the 376 response where pruned by access control, otherwise an attacker could 377 use get/get-config to gather information about the existence of parts 378 of the configuration that is not accessible according to the 379 attackers rights. 381 It is RECOMMENDED that a policy designed to apply to a get or get- 382 config RPC SHOULD match one AttributeValue corresponding to the 383 desired subtree of the data-model with the DataType="&xpath;", the 384 AttributeId="&resource-id;" and the Category="&Resource;". 385 The same element SHOULD contain a match of an AttributeValue 386 corresponding to the desired RPC source (i.e. "running", "startup" or 387 "candidate") with the DataType="&string;", the AttributeId="xacml- 388 netconf:attribute:rpc-source" and the Category="&Resource;". If the 389 policy is to apply to "get" RPCs only this value SHOULD be "running" 390 Furthermore the policy SHOULD match the AttributeValue "read" with 391 the DataType="&string;", the AttributeId="action-id" and the 392 Category="Action". in a element enclosed by a separate 393 element of the policy target. 395 Example request: 397 01 398 02 ... 399 03 400 04 401 05 403 07 /ns1:top[1]/ns1:interface[1] 404 08 405 09 406 10 407 11 408 12 412 16 413 17 read 414 18 415 19 416 20 417 21 418 22 419 23 Ethernet0/0 420 24 1500 421 25 422 26 423 27 Ethernet1/1 424 28 1000 425 29 426 30 427 31 428 32 430 Example policy: 432 01 433 02 434 03 ... 435 04 436 05 437 06 438 07 439 08 440 09 /ns1:top/ns1:interface 441 10 442 11 443 12 446 15 447 16 448 17 running 450 19 453 22 454 23 455 24 456 25 457 26 458 27 459 28 read 460 29 463 32 464 33 465 34 466 35 467 36 468 37 470 5.4. edit-config RPC 472 Requests for edit-config RPCs SHALL be formed as follows: Under the 473 element an Attribute with the 474 AttributeId="&resource-id;" and the DataType="&xpath;". The 475 AttributeValue SHALL be "//*[@operation and not(ancestor::*[@ 476 operation])]". 477 The same Category SHALL also include an Attribute with the 478 AttributeId="&scope;" and the DataType="&string;". The 479 AttributeValue SHALL be "XPath-expression". 481 Still under the same Category there SHALL be an Attribute with the 482 AttributeId="xacml-netconf:attribute:rpc-target" and the DataType="& 483 string;". The AttributeValue SHALL be either "running", "startup" or 484 "candidate" corresponding to the RPC target. 485 Furthermore the request SHALL include the element, containing a single Attribute with the 487 AttributeId="action-id" having the DataType="&string;" and the 488 AttributeValue of "write". 489 From the RPC, the contents of the element SHALL be included 490 in the request under the element. If the RPC contains a 491 element the contents of the RPC element 492 that are added to the request element SHALL be edited to 493 add a xml-attribute "operation" with a value corresponding to the 494 value of the element. 496 This request format makes use of the Multiple resource profile of 497 XACML [XACML_MR] where the multiple resources are the elements of the 498 RPC that have an "operation" xml-attribute and no ancestor with such 499 an xml-attribute. Using this profile, no access control is performed 500 for operations that have an ancestor operation. This is due to the 501 fact that all edit-config operations are subsumed under the action 502 "write" as far as access control is concerned. The underlying 503 assumption of this profile is that if you are authorised to write to 504 a xml-node in the data-model you are automatically authorised to 505 write to all its children too. 506 The XPath "//*[@operation and not(ancestor::*[@operation])]" performs 507 the selection of operations with no ancestor operation. 508 If any edit-config operation of the RPC is not permitted, the whole 509 RPC SHALL be denied. 510 If the RPC uses the :url capability (i.e. a element appears 511 instead of the element), the NETCONF agent SHALL preprocess 512 the RPC by downloading the file pointed to by the URL and replacing 513 the element by a element containing the content of the 514 file. 515 Another special case that needs to be treated is the following: 516 According to the protocol specification, it is possible to create a 517 syntactically correct edit-config RPC with no operation at all (i.e. 518 specifying 'none' as and having no 'operation' 519 xml-attributes in the ). Such an RPC SHALL be discarded 520 according to this profile and not be processed by the NETCONF agent, 521 to avoid leaking information with the error messages. 523 It is RECOMMENDED that a policy designed to apply to an edit-config 524 RPC SHOULD match one AttributeValue corresponding to the desired 525 subtree of the data-model with the DataType="&xpath;", the 526 AttributeId="&resource-id;" and the Category="&Resource;". 527 The same element SHOULD contain a match of an AttributeValue 528 corresponding to the desired RPC target (i.e. "running", "startup" or 529 "candidate") with the DataType="&string;", the AttributeId="xacml- 530 netconf:attribute:rpc-target" and the Category="&Resource;". 531 Furthermore the policy SHOULD match the AttributeValue "write" with 532 the DataType="&string;", the AttributeId="action-id" and the 533 Category="Action" in a element enclosed by a separate 534 element of the policy target. 536 Example request: 538 01 539 02 ... 540 03 541 04 542 05 549 12 553 16 557 20 558 21 write 559 22 560 23 561 24 562 25 563 26 564 27 Ethernet0/0 565 28 1500 566 29 567 30 568 31 569 32 571 Example policy: 573 01 574 02 575 03 ... 576 04 577 05 578 06 579 07 580 08 581 09 /ns1:top/ns1:interface[ns1:name="Ethernet0/0"] 582 10 583 11 584 12 587 15 588 16 589 17 running 591 19 594 22 595 23 596 24 597 25 598 26 599 27 600 28 write 602 30 605 33 606 34 607 35 608 36 609 37 610 38 612 5.5. copy-config and delete-config RPC 614 Requests for copy-config and delete-config RPCs SHALL be formed as 615 follows: The RPC target parameter SHALL be included under the 616 element as a single Attribute with 617 the AttributeId="xacml-netconf:attribute:rpc-target". If the RPC 618 target is one of {running, startup, candidate} the DataType SHALL be 619 "&string;" otherwise it SHALL be "&AnyURI;". The AttributeValue 620 SHALL be equal to the RPC target. 622 In case of copy-config RPCs the request SHALL also include the RPC 623 source under same Category as a single Attribute with the 624 AttributeId="xacml-netconf:attribute:rpc-source". If the RPC source 625 is one of {running, startup, candidate} the DataType SHALL be 626 "&string;" otherwise it SHALL be "&AnyURI;". The AttributeValue 627 SHALL be equal to the RPC source. 628 Furthermore the request SHALL include the element, containing a single Attribute with the 630 AttributeId="action-id" having the DataType="&string;". This SHALL 631 have the AttributeValue of "write" if the RPC target is one of 632 {running, startup, candidate}. If the RPC target is a URL then this 633 AttributeValue SHALL be "read". 634 When the target is a URL, no configuration data is overwritten, such 635 RPC must therefore be considered 'read' operations. However when the 636 target is a local configuration, the RPC must be considered a 'write' 637 operation. 639 It is RECOMMENDED that a policy designed to apply to a copy-config/ 640 delete-config RPC SHOULD match one or more AttributeValues 641 corresponding to the desired RPC targets with AttributeId="xacml- 642 netconf:attribute:rpc-target" and the Category="&Resource;". 643 For those targets that are "running", "startup" or "candidate" the 644 DataType SHALL be equal to "&string;", for URL targets, the DataType 645 SHALL be equal to &AnyURI;. 646 Each desired RPC target SHOULD be placed in a separate 647 element under a single common element in the policy target. 649 The policy SHOULD also match one or more AttributeValues 650 corresponding to the desired RPC sources with the DataType="&string;" 651 or DataType="&AnyURI;", the AttributeId="xacml-netconf:attribute:rpc- 652 source" and the Category="&Resource;". Each desired RPC source 653 SHOULD be placed in a separate element under a single common 654 element in the policy target. 655 Furthermore if any target elements where one of {running, startup, 656 candidate}, then the policy SHOULD match the AttributeValue "write" 657 with the DataType="&string;", the AttributeId="action-id" and the 658 Category="Action" in a separate element enclosed by a 659 separate element in the policy target. 660 If any source elements where one of {running, startup, candidate}, 661 then the policy SHOULD match the AttributeValue "read" with the 662 DataType="&string;", the AttributeId="action-id" and the 663 Category="Action" in a separate element. This element should 664 be enclosed the same element as previous "write" action 665 matches if any, otherwise it is to be enclosed by a separate 666 element in the policy target. 668 Example request: 670 01 671 02 ... 672 03 673 04 674 05 677 08 682 13 683 14 write 684 15 685 16 686 17 688 Example policy: 690 01 691 02 692 03 ... 693 04 694 05 695 06 696 07 running 698 09 701 12 702 13 703 14 704 15 705 16 706 17 707 18 https://user@example.com: 709 20 passphrase/cfg/new.txt 710 21 713 24 714 25 715 26 716 27 717 28 718 29 719 30 write 721 32 724 35 725 36 726 37 727 38 728 39 729 40 731 5.6. lock and unlock RPC 733 Requests for lock/unlock RPCs SHALL be formed as follows: The RPC 734 operation target SHALL be included under the element as a single Attribute with the 736 AttributeId="xacml-netconf:attribute:rpc-target" and the DataType="& 737 string;". The AttributeValue SHALL be either "running", "startup" or 738 "candidate" corresponding to the RPC operation target. 739 Furthermore the request SHALL include the element, containing a single Attribute with the 741 AttributeId="action-id" having the DataType="&string;" and the 742 AttributeValue of either "lock" or "unlock" depending on the type of 743 RPC. 745 It is RECOMMENDED that a policy designed to apply to a lock/unlock 746 RPC SHOULD match one or more AttributeValues corresponding to the 747 desired RPC targets (i.e. "running", "startup" and/or "candidate") 748 with the DataType="&string;", the AttributeId="xacml- 749 netconf:attribute:rpc-target" and the Category="&Resource;". Each 750 desired RPC target SHOULD be placed in a separate element 751 under a single element in the policy target. Furthermore the 752 policy SHOULD match both AttributeValues "lock" and "unlock" with the 753 DataType="&string;", the AttributeId="action-id" and the 754 Category="Action". in separate elements enclosed by a 755 separate element of the policy target. 757 Example request: 759 01 760 02 ... 761 03 762 04 763 05 767 09 768 10 lock 769 11 770 12 771 13 773 Example policy: 775 01 776 02 777 03 ... 778 04 779 05 780 06 781 07 running 783 09 786 12 787 13 788 14 789 15 790 16 791 17 792 18 lock 794 20 797 23 798 24 799 25 800 26 801 27 unlock 803 29 806 32 807 33 808 34 809 35 810 36 811 37 813 5.7. kill-session RPC 815 Requests and policies for this RPC are defined to be independent of 816 the session-id. Although it would be easily possible to make 817 session-id specific policies and requests, no reasonable use-case for 818 such a feature was found. 820 Any kill-session RPC SHALL be translated to a request that includes 821 the element, containing a single 822 Attribute with the AttributeId="action-id" having the DataType="& 823 string;" and the AttributeValue "kill-session". 824 It is RECOMMENDED that a policy designed to apply to a kill-session 825 RPC SHOULD match the single AttributeValue "kill-session" with the 826 DataType="&string;", the AttributeId="action-id" and the 827 Category="Action" in a element of its Target. 829 Example request: 831 01 832 02 ... 833 03 834 04 835 05 kill-session 837 07 838 08 839 09 841 Example policy: 843 01 844 02 845 03 ... 846 04 847 05 848 06 849 07 kill-session 851 09 854 12 855 13 856 14 857 15 858 16 859 17 861 5.8. close-session RPC 863 For this RPC it was deemed that no XACML profile was necessary. This 864 results from the assumption that only the person that opened a 865 session should be allowed to submit this RPC to the NETCONF agent. 866 It seems reasonable to expect that the NETCONF agent can enforce this 867 behaviour without the support of the access control system. 869 5.9. commit and discard-changes RPC 871 If the NETCONF agent supports the :candidate capability, Any commit 872 or discard-changes RPC SHALL be translated to a request that includes 873 the element, containing a single 874 Attribute with the AttributeId="action-id" having the DataType="& 875 string;" and the AttributeValue of either "commit" or "discard- 876 changes". 877 It is RECOMMENDED that a policy designed to apply to a commit or 878 discard-changes RPC SHOULD match the single AttributeValue "commit" 879 or "discard-changes" with the DataType="&string;", the 880 AttributeId="action-id" and the Category="Action" in a 881 element enclosed by a element of its Target. 883 Example request: 885 01 886 02 ... 887 03 888 04 889 05 commit 890 06 891 07 892 08 894 Example policy: 896 01 897 02 898 03 ... 899 04 900 05 901 06 902 07 commit 904 09 907 12 908 13 909 14 910 15 911 16 912 17 914 5.10. validate RPC 916 If the NETCONF agent supports the :validate capability, requests for 917 lock/unlock RPCs SHALL be formed as follows: The RPC operation target 918 SHALL be included under the 919 element as a single Attribute with the AttributeId="xacml- 920 netconf:attribute:rpc-target" and the DataType="&string;". The 921 AttributeValue SHALL be either "running", "startup" or "candidate" 922 corresponding to the RPC operation target. 923 Furthermore the request SHALL include the element, containing a single Attribute with the 925 AttributeId="action-id" having the DataType="&string;" and the 926 AttributeValue of "validate". 928 It is RECOMMENDED that a policy designed to apply to a validate RPC 929 SHOULD match one or more AttributeValues corresponding to the desired 930 RPC targets (i.e. "running", "startup" and/or "candidate") with the 931 DataType="&string;", the AttributeId="xacml-netconf:attribute:rpc- 932 target" and the Category="&Resource;". Each desired RPC target 933 SHOULD be placed in a separate element under a single 934 element in the policy target. Furthermore the policy SHOULD match 935 the AttributeValue "validate" with the DataType="&string;", the 936 AttributeId="action-id" and the Category="Action" in a separate 937 element enclosed by a separate element of the policy 938 target. 940 Example request: 942 01 943 02 ... 944 03 945 04 946 05 950 09 951 10 validate 952 11 953 12 954 13 956 Example policy: 958 01 959 02 960 03 ... 961 04 962 05 963 06 964 07 candidate 966 09 969 12 970 13 971 14 972 15 973 16 974 17 975 18 validate 977 20 980 23 981 24 982 25 983 26 984 27 985 28 987 6. Practical consequences for NETCONF implementations 989 This profile does not make any assumptions on the data-model that a 990 NETCONF operation affects. However writing a correct policy 991 according to this profile requires such knowledge. This is due to 992 the fact that XPathes matching parts of the data-model have to be 993 inserted in the policy. 995 A PDP using this profile to perform access control on NETCONF 996 operations will need access to the RPC and for or 997 operations, to the results of the RPC. No access to actual device 998 data is required by this profile. If a special treatment for get/ 999 get-config proves to be undesirable, a more restrictive 1000 interpretation can be implemented by performing a similar access 1001 control evaluation as for edit-config RPCs. 1003 This profile makes heavy use of XPath [XPath] to reference elements 1004 in a data-model. It may be the case that XPath processing proves to 1005 be too slow for time-critical applications. Therefore alternatives 1006 can be considered, such as the Subtree Filtering proposed in the 1007 Netconf standard section 6 [RFC4741]. This profile can be adapted to 1008 such alternatives with relative ease, by creating a new data-type for 1009 XACML representing the xml-node selection expression and a new 1010 function for XACML equivalent to the "xpath-node-match" Function. 1012 According to this profile, no specific access control architecture is 1013 required (i.e. where the PDP and PEP are implemented). However it 1014 seems both advisable and possible to have the PDP running at the same 1015 location as the NETCONF agent. Although calls to distant PDPs are 1016 possible the response time would be prohibitive. In order to allow 1017 for fast communication one should aim to have the PDP running in the 1018 same process as the NETCONF agent. Our implementation of the XACML 1019 PDP is around 300 KByte large and has a memory consumption in the 1020 order of magnitude of 700 KBytes (this is mostly due to XML 1021 processing at startup). Further optimisation of these numbers is 1022 possible if need arises. 1024 If the NETCONF agent supports the :url capability, edit-config RPCs 1025 need to be preprocessed to substitute a possible element by a 1026 element containing the contents of the file pointed to by 1027 the URL. 1029 7. Security Considerations 1031 Depending on the error messages returned by unsuccessful edit-config 1032 operations, an attacker might probe parts of the data model that are 1033 not covered by the attackers access rights. Especially the 'data- 1034 exists' and 'data-missing' errors could leak information about the 1035 device data. If these leaks are considered severe, one should 1036 consider replacing the error message e.g. with an 'operation-failed' 1037 error message without further description. 1039 New capabilities advertised by NETCONF agents can provide new methods 1040 of accessing data on the device. If the access control model does 1041 not cover such capabilities it is RECOMMENDED to deny requests using 1042 them until the model has been extended to cover them. 1043 In order to implement such behaviour for new NETCONF operations, a 1044 deny-biased PDP can be used. Such a PDP denies all requests for 1045 which no applicable policy can be found. 1046 If the capability affects existing NETCONF operations, the specific 1047 profile for these operations SHOULD be extended. 1049 Security considerations from the XACML standard [XACML] and from the 1050 NETCONF standard [RFC4741] SHOULD be applied to any use of this 1051 profile. 1053 8. References 1055 8.1. Normative References 1057 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1058 Requirement Levels", BCP 14, RFC 2119, March 1997. 1060 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1061 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1062 D. Spence, "AAA Authorization Framework", RFC 2904, 1063 August 2000. 1065 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1066 December 2006. 1068 [XACML] OASIS, "eXtensible Access Control Markup Language", 1069 . 1071 [XACML_MR] 1072 Anderson, A., "Multiple resource profile of XACML v2.0", 1073 OASIS Standard, February 2005. 1075 [XML] Bray, T., Paoli, J., Maler, E., Sperberg-McQueen, C., and 1076 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1077 Edition)", World Wide Web Consortium Recommendation REC- 1078 xml-20060816, August 2006, 1079 . 1081 [XPath] DeRose, S. and J. Clark, "XML Path Language (XPath) 1082 Version 1.0", World Wide Web Consortium 1083 Recommendation REC-xpath-19991116, November 1999, 1084 . 1086 8.2. Informative References 1088 [XACMLIntro] 1089 Sun Microsystems, Inc., "A Brief Introduction to XACML", 1090 Webpage http://www.oasis-open.org/committees/download.php/ 1091 2713/Brief_Introduction_to_XACML.html, March 2003. 1093 [XACMLProducts] 1094 Anderson, A., "XACML References and Products, Version 1095 1.73", 1096 Webpage http://docs.oasis-open.org/xacml/xacmlRefs.html, 1097 January 2007. 1099 Appendix A. Abbreviations 1101 For abbreviating XACML policies and requests this profile provides a 1102 list of entity declarations, that is to be used within this document. 1103 The syntax and expansion for such entities is defined in [XML] (e.g. 1104 &string; will be expanded to 1105 "http://www.w3.org/2001/XMLSchema#string"). 1107 o 1110 o 1113 o 1116 o 1118 o 1121 o 1123 o 1126 o 1129 o 1131 Appendix B. Examples 1133 In this section we give examples of requests, policies and their 1134 evaluation. 1136 B.1. Get-config example 1138 Given the following get-config RPC: 1140 01 1142 03 1143 04 1144 05 1145 06 1146 07 1147 08 1148 09 1149 10 1150 11 1152 we get the following result before access control: 1154 01 1156 03 1157 04 1158 05 1159 06 Ethernet 1160 07 1161 08 Ethernet0/0 1162 09 1500 1163 10 1164 11 1165 12 Ehternet1/1 1166 13 3000 1167 14 1168 15 1169 16 Ethernet2/2 1170 17 1000 1171 18 1172 19 1173 20 1174 21 WLAN 1175 22 1176 23 WLAN0/0 1177 24 1178 25 1179 26 1180 27 1181 28 1183 Now given and the XACML policy (omitting the subject part): 1185 01 1186 02 1187 03 ... 1188 04 1189 05 1190 06 1191 07 1192 08 /top/interfaces[name="Ethernet"] 1193 09 1194 10 1197 13 1198 14 1199 15 running 1201 17 1204 20 1205 21 1206 22 1207 23 1208 24 1209 25 1210 26 read 1212 28 1215 31 1216 32 1217 33 1218 34 1219 35 1220 36 1222 we generate the following requests (omitting the subject part): 1224 01 1225 02 ... 1226 03 1227 04 1228 05 1233 10 1237 14 1238 15 read 1239 16 1240 17 1241 18 1242 19 ... 1243 20 1244 21 1246 which is denied. 1248 01 1249 02 ... 1250 03 1251 04 1252 05 1264 04 1265 05 1277 04 1278 05 1290 04 1291 05 1303 04 1304 05 1316 04 1317 05 1329 03 1330 04 1331 05 1332 06 Ethernet 1333 07 1334 08 Ethernet0/0 1335 09 1500 1336 10 1337 11 1338 12 Ehternet1/1 1339 13 3000 1340 14 1341 15 1342 16 Ethernet2/2 1343 17 1000 1344 18 1345 19 1346 20 1347 21 1348 22 1350 B.2. edit-config example 1352 Given the following edit-config RPC: 1354 01 1356 03 1357 04 1358 05 1359 06 1360 07 1361 08 Ethernet 1362 09 1363 10 Ethernet0/0 1364 11 1500 1365 12 192.0.0.1 1366 13 1367 14 1368 15 Ethernet1/1 1369 16 3000 1370 17 1371 18 1372 19 Ethernet2/2 1373 20 1000 1374 21 1375 22 1376 23 1377 24 WLAN 1378 25 1379 26 WLAN0/0 1380 27 1381 28 1382 29 1383 30 1384 31 1385 32 1387 and the following XACML policy (omitting the subject part): 1389 01 1390 02 1391 03 ... 1392 04 1393 05 1394 06 1395 07 1396 08 /top/interfaces[name="Ethernet"] 1397 09 1398 10 1401 13 1402 14 1403 15 running 1405 17 1408 20 1409 21 1410 22 1411 23 1412 24 1413 25 1414 26 write 1416 28 1419 31 1420 32 1421 33 1422 34 1423 35 1424 36 1426 we generate the following request from the RPC: 1428 01 1429 02 1430 03 1431 04 running 1432 05 1433 06 1434 07 XPath-expression 1436 09 1437 10 1438 11 1445 18 1446 19 write 1447 20 1448 21 1449 22 1450 23 [Contents of the element in the RPC] 1451 24 1452 25 1454 which results in the following XACML response: 1456 01 1457 02 1458 03 Permit 1459 04 1460 05 1462 07 1463 08 /top[1]/interfaces[1]/interface[1] 1464 09 1465 10 1466 11 1467 12 1468 13 1469 14 1470 15 1471 16 1472 17 NotApplicable 1473 18 1474 19 1476 21 1483 28 1484 29 1485 30 1486 31 Permit 1487 32 1488 33 1490 35 1491 36 /top[1]/interfaces[1]/interface[2] 1492 37 1493 38 1494 39 1495 40 1496 41 1497 42 1498 43 1499 44 1500 45 Permit 1501 46 1502 47 1504 49 1505 50 /top[1]/interfaces[1]/interface[3]/mtu[1] 1506 47 1507 48 1508 49 1509 50 1510 51 1511 52 1512 53 1513 54 1515 The meaning of this response is the following: 1517 o The operation on line 09 of the RPC is permitted (lines 02-14 of 1518 the response). 1520 o There is no applicable policy for the operation on line 25 of the 1521 RPC (lines 15-27 of the response). This usually means that we 1522 deny the operation and therefore reject the whole RPC. 1524 o The operation on line 14 of the RPC is permitted (line 28-40 of 1525 the response). 1527 o The operation on line 20 of the RPC is permitted (line 41-53 of 1528 the response). 1530 The operation on line 12 of the RPC is not submitted to access 1531 control since a ancestor xml-element already contained a edit-config 1532 operation (line 09). Since we simplify all edit-config operations to 1533 'write', the operation on line 12 would have been permitted anyway as 1534 the ancestor operation was permitted. If the ancestor operation had 1535 been denied the whole RPC would be rejected anyway. 1537 Authors' Addresses 1539 Ludwig Seitz 1540 SICS, Swedish Institute of Computer Science AB 1541 Box 1263 1542 Kista 164 29 1543 Sweden 1545 Phone: +46 8 633 1516 1546 Email: ludwig@sics.se 1548 Erik Rissanen 1549 Axiomatics AB 1550 Ringstedsgatan 36 1551 Kista 164 48 1552 Sweden 1554 Email: erik@axiomatics.com 1556 Full Copyright Statement 1558 Copyright (C) The IETF Trust (2007). 1560 This document is subject to the rights, licenses and restrictions 1561 contained in BCP 78, and except as set forth therein, the authors 1562 retain all their rights. 1564 This document and the information contained herein are provided on an 1565 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1566 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1567 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1568 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1569 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1570 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1572 Intellectual Property 1574 The IETF takes no position regarding the validity or scope of any 1575 Intellectual Property Rights or other rights that might be claimed to 1576 pertain to the implementation or use of the technology described in 1577 this document or the extent to which any license under such rights 1578 might or might not be available; nor does it represent that it has 1579 made any independent effort to identify any such rights. Information 1580 on the procedures with respect to rights in RFC documents can be 1581 found in BCP 78 and BCP 79. 1583 Copies of IPR disclosures made to the IETF Secretariat and any 1584 assurances of licenses to be made available, or the result of an 1585 attempt made to obtain a general license or permission for the use of 1586 such proprietary rights by implementers or users of this 1587 specification can be obtained from the IETF on-line IPR repository at 1588 http://www.ietf.org/ipr. 1590 The IETF invites any interested party to bring to its attention any 1591 copyrights, patents or patent applications, or other proprietary 1592 rights that may cover technology that may be required to implement 1593 this standard. Please address the information to the IETF at 1594 ietf-ipr@ietf.org. 1596 Acknowledgment 1598 Funding for the RFC Editor function is provided by the IETF 1599 Administrative Support Activity (IASA).