draft-ietf-netconf-access-control-05.txt   draft-ietf-netconf-access-control-06.txt 
Internet Engineering Task Force A. Bierman Internet Engineering Task Force A. Bierman
Internet-Draft Brocade Internet-Draft Brocade
Intended status: Standards Track M. Bjorklund Intended status: Standards Track M. Bjorklund
Expires: April 6, 2012 Tail-f Systems Expires: May 3, 2012 Tail-f Systems
October 4, 2011 October 31, 2011
Network Configuration Protocol (NETCONF) Access Control Model Network Configuration Protocol (NETCONF) Access Control Model
draft-ietf-netconf-access-control-05 draft-ietf-netconf-access-control-06
Abstract Abstract
The standardization of network configuration interfaces for use with The standardization of network configuration interfaces for use with
the NETCONF protocol requires a structured and secure operating the NETCONF protocol requires a structured and secure operating
environment that promotes human usability and multi-vendor environment that promotes human usability and multi-vendor
interoperability. There is a need for standard mechanisms to interoperability. There is a need for standard mechanisms to
restrict NETCONF protocol access for particular users to a pre- restrict NETCONF protocol access for particular users to a pre-
configured subset of all available NETCONF protocol operations and configured subset of all available NETCONF protocol operations and
content. This document defines such an access control model. content. This document defines such an access control model.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3.2. Datastore Access . . . . . . . . . . . . . . . . . . . . . 13 3.2. Datastore Access . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Access Rights . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Access Rights . . . . . . . . . . . . . . . . . . . . 13
3.2.2. <get> and <get-config> Operations . . . . . . . . . . 14 3.2.2. <get> and <get-config> Operations . . . . . . . . . . 14
3.2.3. <edit-config> Operation . . . . . . . . . . . . . . . 14 3.2.3. <edit-config> Operation . . . . . . . . . . . . . . . 14
3.2.4. <copy-config> Operation . . . . . . . . . . . . . . . 15 3.2.4. <copy-config> Operation . . . . . . . . . . . . . . . 15
3.2.5. <delete-config> Operation . . . . . . . . . . . . . . 16 3.2.5. <delete-config> Operation . . . . . . . . . . . . . . 16
3.2.6. <commit> Operation . . . . . . . . . . . . . . . . . . 16 3.2.6. <commit> Operation . . . . . . . . . . . . . . . . . . 16
3.2.7. <discard-changes> Operation . . . . . . . . . . . . . 16 3.2.7. <discard-changes> Operation . . . . . . . . . . . . . 16
3.2.8. <kill-session> Operation . . . . . . . . . . . . . . . 16 3.2.8. <kill-session> Operation . . . . . . . . . . . . . . . 16
3.3. Model Components . . . . . . . . . . . . . . . . . . . . . 16 3.3. Model Components . . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Users . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.1. Users . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Groups . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.2. Groups . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3. Global Enforcement Controls . . . . . . . . . . . . . 17 3.3.3. Global Enforcement Controls . . . . . . . . . . . . . 17
3.3.3.1. enable-nacm Switch . . . . . . . . . . . . . . . . 17 3.3.3.1. enable-nacm Switch . . . . . . . . . . . . . . . . 17
3.3.3.2. read-default Switch . . . . . . . . . . . . . . . 17 3.3.3.2. read-default Switch . . . . . . . . . . . . . . . 17
3.3.3.3. write-default Switch . . . . . . . . . . . . . . . 18 3.3.3.3. write-default Switch . . . . . . . . . . . . . . . 18
3.3.3.4. exec-default Switch . . . . . . . . . . . . . . . 18 3.3.3.4. exec-default Switch . . . . . . . . . . . . . . . 18
3.3.4. Access Control Rules . . . . . . . . . . . . . . . . . 18 3.3.4. Access Control Rules . . . . . . . . . . . . . . . . . 18
3.4. Access Control Enforcement Procedures . . . . . . . . . . 19 3.4. Access Control Enforcement Procedures . . . . . . . . . . 19
3.4.1. Initial Operation . . . . . . . . . . . . . . . . . . 19 3.4.1. Initial Operation . . . . . . . . . . . . . . . . . . 19
3.4.2. Session Establishment . . . . . . . . . . . . . . . . 19 3.4.2. Session Establishment . . . . . . . . . . . . . . . . 19
3.4.3. "access-denied" Error Handling . . . . . . . . . . . . 19 3.4.3. "access-denied" Error Handling . . . . . . . . . . . . 20
3.4.4. Incoming RPC Message Validation . . . . . . . . . . . 20 3.4.4. Incoming RPC Message Validation . . . . . . . . . . . 20
3.4.5. Data Node Access Validation . . . . . . . . . . . . . 22 3.4.5. Data Node Access Validation . . . . . . . . . . . . . 23
3.4.6. Outgoing <notification> Authorization . . . . . . . . 24 3.4.6. Outgoing <notification> Authorization . . . . . . . . 25
3.5. Data Model Definitions . . . . . . . . . . . . . . . . . . 26 3.5. Data Model Definitions . . . . . . . . . . . . . . . . . . 27
3.5.1. Data Organization . . . . . . . . . . . . . . . . . . 27 3.5.1. Data Organization . . . . . . . . . . . . . . . . . . 28
3.5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 27 3.5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 28
3.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 37 3.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 38
3.7. Security Considerations . . . . . . . . . . . . . . . . . 37 3.7. Security Considerations . . . . . . . . . . . . . . . . . 38
3.7.1. NACM Configuration and Monitoring Considerations . . . 37 3.7.1. NACM Configuration and Monitoring Considerations . . . 38
3.7.2. General Configuration Issues . . . . . . . . . . . . . 39 3.7.2. General Configuration Issues . . . . . . . . . . . . . 40
3.7.3. Data Model Design Considerations . . . . . . . . . . . 40 3.7.3. Data Model Design Considerations . . . . . . . . . . . 41
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1. Normative References . . . . . . . . . . . . . . . . . . . 41 4.1. Normative References . . . . . . . . . . . . . . . . . . . 43
4.2. Informative References . . . . . . . . . . . . . . . . . . 41 4.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 42 Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 44
A.1. <groups> Example . . . . . . . . . . . . . . . . . . . . . 42 A.1. <groups> Example . . . . . . . . . . . . . . . . . . . . . 44
A.2. Module Rule Example . . . . . . . . . . . . . . . . . . . 43 A.2. Module Rule Example . . . . . . . . . . . . . . . . . . . 45
A.3. RPC Rule Example . . . . . . . . . . . . . . . . . . . . . 44 A.3. RPC Rule Example . . . . . . . . . . . . . . . . . . . . . 46
A.4. Data Rule Example . . . . . . . . . . . . . . . . . . . . 46 A.4. Data Rule Example . . . . . . . . . . . . . . . . . . . . 48
A.5. Notification Rule Example . . . . . . . . . . . . . . . . 48 A.5. Notification Rule Example . . . . . . . . . . . . . . . . 50
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 52
B.1. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 50 B.1. 05-06 . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.2. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 50 B.2. 04-05 . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.3. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 50 B.3. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.4. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 51 B.4. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.5. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 51 B.5. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.6. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 B.6. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 B.7. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
The NETCONF protocol does not provide any standard mechanisms to The NETCONF protocol does not provide any standard mechanisms to
restrict the protocol operations and content that each user is restrict the protocol operations and content that each user is
authorized to access. authorized to access.
There is a need for inter-operable management of the controlled There is a need for inter-operable management of the controlled
access to administrator selected portions of the available NETCONF access to administrator selected portions of the available NETCONF
content within a particular server. content within a particular server.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
operations. operations.
datastore: Permission to read and/or alter specific data nodes datastore: Permission to read and/or alter specific data nodes
within any datastore. within any datastore.
notification: Permission to receive specific notification event notification: Permission to receive specific notification event
types. types.
2.2. Simplicity 2.2. Simplicity
Experience has shown that a complicated ACM will not be widely There is concern that a complicated ACM will not be widely deployed,
deployed, because it is too hard to use. The key factor that is because it is too hard to use. It needs to be easy to do simple
ignored in such solutions is the concept of "localized cost". It things, and possible to do complex things, instead of hard to do
needs to be easy to do simple things, and possible to do complex everything.
things, instead of hard to do everything.
Configuration of the access control system needs to be as simple as Configuration of the access control system needs to be as simple as
possible. Simple and common tasks need to be easy to configure, and possible. Simple and common tasks need to be easy to configure, and
require little expertise or domain-specific knowledge. Complex tasks require little expertise or domain-specific knowledge. Complex tasks
are possible using additional mechanisms, which may require are possible using additional mechanisms, which may require
additional expertise. additional expertise.
A single set of access control rules ought to be able to control all A single set of access control rules ought to be able to control all
types of NETCONF protocol operation invocation, all datastore access, types of NETCONF protocol operation invocation, all datastore access,
and all notification events. and all notification events.
skipping to change at page 13, line 11 skipping to change at page 13, line 11
o Access control is applied to all <rpc> messages (except <close- o Access control is applied to all <rpc> messages (except <close-
session>) received by the server, individually, for each active session>) received by the server, individually, for each active
session, unless the session is identified as a "recovery session". session, unless the session is identified as a "recovery session".
o If the user is authorized to execute the specified protocol o If the user is authorized to execute the specified protocol
operation, then processing continues, otherwise the request is operation, then processing continues, otherwise the request is
rejected with an "access-denied" error. rejected with an "access-denied" error.
o If the configuration datastore or conceptual state data is o If the configuration datastore or conceptual state data is
accessed by the protocol operation, then the data node access MUST accessed by the protocol operation, then the server checks if the
be authorized. If the user is authorized to perform the requested client is authorized to access the nodes in the data store. If
access operation on the requested data, then processing continues. the user is authorized to perform the requested access operation
on the requested data, then processing continues.
The following sequence of conceptual processing steps is executed for The following sequence of conceptual processing steps is executed for
each generated notification event, if access control enforcement is each generated notification event, if access control enforcement is
enabled: enabled:
o Server instrumentation generates a notification, for a particular o Server instrumentation generates a notification, for a particular
subscription. subscription.
o The notification access control enforcer checks the notification o The notification access control enforcer checks the notification
event type, and if it is one which the user is not authorized to event type, and if it is one which the user is not authorized to
read, then the notification is dropped for that subscription. read, then the notification is dropped for that subscription.
3.2. Datastore Access 3.2. Datastore Access
The same access control rules apply to all datastores. For example, The same access control rules apply to all datastores. For example,
the candidate configuration datastore or the running configuration the candidate configuration datastore or the running configuration
datastore. datastore.
Only the standard NETCONF datastores (candidate, running, and Only the standard NETCONF datastores (candidate, running, and
startup) are controlled by the ACM. Local or remote files or startup) are controlled by NACM. Local or remote files or datastores
datastores accessed via the <url> parameter are optional to support. accessed via the <url> parameter are not controlled by NACM.
3.2.1. Access Rights 3.2.1. Access Rights
A small set of hard-wired datastore access rights is needed to A small set of hard-wired datastore access rights is needed to
control access to all possible NETCONF protocol operations, including control access to all possible NETCONF protocol operations, including
vendor extensions to the standard protocol operation set. vendor extensions to the standard protocol operation set.
The "CRUDX" model can support all NETCONF protocol operations: The "CRUDX" model can support all NETCONF protocol operations:
o Create: Allows the client to add a new data node instance to a o Create: Allows the client to add a new data node instance to a
skipping to change at page 14, line 32 skipping to change at page 14, line 35
The NACM access rights are not directly coupled to the <edit-config> The NACM access rights are not directly coupled to the <edit-config>
"operation" attribute, although they are similar. Instead, a NACM "operation" attribute, although they are similar. Instead, a NACM
access right applies to all protocol operations which would result in access right applies to all protocol operations which would result in
a particular access operation to the target datastore. This section a particular access operation to the target datastore. This section
describes how these access rights apply to the specific access describes how these access rights apply to the specific access
operations supported by the <edit-config> protocol operation. operations supported by the <edit-config> protocol operation.
If the effective access operation is "none" (i.e., default- If the effective access operation is "none" (i.e., default-
operation="none") for a particular data node, then no access control operation="none") for a particular data node, then no access control
is applied to that data node. is applied to that data node. This is required to allow access to a
sub-tree within larger data structure. For example, a user may be
authorized to create a new "/interfaces/interface" list entry, but
not be authorized to create or delete its parent container
("/interfaces"). If the "/interfaces" container already exists in
the target datastore, then the effective operation will be "none" for
the "/interfaces" node if an "/interfaces/interface" list entry is
edited.
If the protocol operation would result in the creation of a data If the protocol operation would result in the creation of a data
store node, and the user does not have "create" access permission for store node, and the user does not have "create" access permission for
that node, the protocol operation is rejected with an "access-denied" that node, the protocol operation is rejected with an "access-denied"
error. error.
If the protocol operation would result in the deletion of a data If the protocol operation would result in the deletion of a data
store node, and the user does not have "delete" access permission for store node, and the user does not have "delete" access permission for
that node, the protocol operation is rejected with an "access-denied" that node, the protocol operation is rejected with an "access-denied"
error. error.
skipping to change at page 20, line 32 skipping to change at page 21, line 23
V V
+------------+ +------------+
| NC-base NS | | NC-base NS |
| <rpc> | | <rpc> |
+------------+ +------------+
| | | | | |
| | +-------------------------+ | | +-------------------------+
| +------------+ | | +------------+ |
V V V V V V
+-----------+ +---------------+ +------------+ +-----------+ +---------------+ +------------+
| acme NS | | NC-base NS | | NC-base NS | | Vendor NS | | NC-base NS | | NC-base NS |
| <my-edit> | | <edit-config> | | <unlock> | | <my-edit> | | <edit-config> | | <unlock> |
+-----------+ +---------------+ +------------+ +-----------+ +---------------+ +------------+
| | | |
| | | |
V V V V
+----------------------+ +----------------------+
| | | |
| configuration | | configuration |
| datastore | | datastore |
+----------------------+ +----------------------+
Figure 3 Figure 3
Access control begins with the message dispatcher. Access control begins with the message dispatcher.
After the server validates the <rpc> element, and determines the After the server validates the <rpc> element, and determines the
namespace URI and the element name of the protocol operation being namespace URI and the element name of the protocol operation being
requested, the server verifies that the user is authorized to invoke requested, the server verifies that the user is authorized to invoke
the protocol operation. the protocol operation.
The protocol operation is authorized by following these steps: The server MUST separately authorize every protocol operation by
following these steps:
1. If the "enable-nacm" leaf is set to "false", then the protocol 1. If the "enable-nacm" leaf is set to "false", then the protocol
operation is permitted. operation is permitted.
2. If the requesting session is identified as a "recovery session", 2. If the requesting session is identified as a "recovery session",
then the protocol operation is permitted. then the protocol operation is permitted.
3. If the requested operation is the NETCONF <close-session> 3. If the requested operation is the NETCONF <close-session>
protocol operation, then the protocol operation is permitted. protocol operation, then the protocol operation is permitted.
skipping to change at page 25, line 38 skipping to change at page 26, line 38
+------------------------+ +------------------------+
| ^ | ^
V | V |
+----------------------+ +----------------------+
| configuration | | configuration |
| datastore | | datastore |
+----------------------+ +----------------------+
Figure 4 Figure 4
The generation of a notification for a specific subscription is The generation of a notification for a specific subscription
authorized by following these steps: [RFC5277] is authorized by following these steps:
1. If the "enable-nacm" leaf is set to "false", then the 1. If the "enable-nacm" leaf is set to "false", then the
notification is permitted. notification is permitted.
2. If the session is identified as a "recovery session", then the 2. If the session is identified as a "recovery session", then the
notification is permitted. notification is permitted.
3. If the notification is the NETCONF <replayComplete> or 3. If the notification is the NETCONF <replayComplete> or
<notificationComplete> event type [RFC5277], then the <notificationComplete> event type [RFC5277], then the
notification is permitted. notification is permitted.
skipping to change at page 27, line 47 skipping to change at page 28, line 47
+--rw comment? string +--rw comment? string
3.5.2. YANG Module 3.5.2. YANG Module
The following YANG module specifies the normative NETCONF content The following YANG module specifies the normative NETCONF content
that MUST by supported by the server. that MUST by supported by the server.
The "ietf-netconf-acm" YANG module imports typedefs from [RFC6021]. The "ietf-netconf-acm" YANG module imports typedefs from [RFC6021].
// RFC Ed.: please update the date to the date of publication // RFC Ed.: please update the date to the date of publication
<CODE BEGINS> file="ietf-netconf-acm@2011-10-04.yang" <CODE BEGINS> file="ietf-netconf-acm@2011-10-31.yang"
module ietf-netconf-acm { module ietf-netconf-acm {
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm"; namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-acm";
prefix "nacm"; prefix "nacm";
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
skipping to change at page 28, line 48 skipping to change at page 29, line 48
License set forth in Section 4.c of the IETF Trust's License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and // RFC Ed.: replace XXXX with actual RFC number and
// remove this note // remove this note
// RFC Ed.: remove this note // RFC Ed.: remove this note
// Note: extracted from draft-ietf-netconf-access-control-05.txt // Note: extracted from draft-ietf-netconf-access-control-06.txt
// RFC Ed.: please update the date to the date of publication // RFC Ed.: please update the date to the date of publication
revision "2011-10-04" { revision "2011-10-31" {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Network Configuration Protocol "RFC XXXX: Network Configuration Protocol
Access Control Model"; Access Control Model";
} }
/* /*
* Extension statements * Extension statements
*/ */
skipping to change at page 38, line 27 skipping to change at page 39, line 27
o /nacm/write-default (default "deny") o /nacm/write-default (default "deny")
o /nacm/exec-default (default "permit") o /nacm/exec-default (default "permit")
An administrator needs to restrict write access to all configurable An administrator needs to restrict write access to all configurable
objects within this data model. objects within this data model.
If write access is allowed for configuration of access control rules, If write access is allowed for configuration of access control rules,
then care needs to be taken not to disrupt the access control then care needs to be taken not to disrupt the access control
enforcement. For example, if the NACM access control rules are enforcement. For example, if the NACM access control rules are
editing directly within the running configuration datastore (i.e., edited directly within the running configuration datastore (i.e.,
:writable-running capability is supported and used), then care needs :writable-running capability is supported and used), then care needs
to be taken not to allow unintended access while the edits are being to be taken not to allow unintended access while the edits are being
done. done.
NACM requires some a user name in each NACM group mapping. An An administrator needs to make sure that the translation from a
administrator needs to make sure that the translation from a
transport or implementation dependant user identity to a NACM user transport or implementation dependant user identity to a NACM user
name is unique. name is unique and correct. This requirement is specified in detail
in section 2.2 of [RFC6241].
An administrator needs to be aware that the YANG data structures
representing access control rules (/nacm/rule-list and /nacm/
rule-list/rule) are ordered by the client. The server will evaluate
the access control rules according to their relative conceptual order
within the running datastore configuration.
Note that the /nacm/groups data structure contains the administrative
group names used by the server. These group names may be configured
locally and/or provided through an external protocol, such as RADIUS
[RFC2865] [RFC5607].
An administrator needs to restrict read access to the following An administrator needs to restrict read access to the following
objects within this data model, which reveal access control objects within this data model, which reveal access control
configuration which could be considered sensitive. configuration which could be considered sensitive.
o /nacm/enable-nacm o /nacm/enable-nacm
o /nacm/read-default o /nacm/read-default
o /nacm/write-default o /nacm/write-default
skipping to change at page 39, line 22 skipping to change at page 40, line 34
It is possible for a session with some write access (e.g., allowed to It is possible for a session with some write access (e.g., allowed to
invoke <edit-config>), but without any access to a particular invoke <edit-config>), but without any access to a particular
datastore subtree containing sensitive data, to determine the datastore subtree containing sensitive data, to determine the
presence or non-presence of that data. This can be done by presence or non-presence of that data. This can be done by
repeatedly issuing some sort of edit request (create, update, or repeatedly issuing some sort of edit request (create, update, or
delete) and possibly receiving "access-denied" errors in response. delete) and possibly receiving "access-denied" errors in response.
These "fishing" attacks can identify the presence or non-presence of These "fishing" attacks can identify the presence or non-presence of
specific sensitive data even without the "error-path" field being specific sensitive data even without the "error-path" field being
present within the "rpc-error" response. present within the "rpc-error" response.
It may be possible for the set of NETCONF capabilities on the server
to change over time. If so, then there is a risk that new protocol
operations, notifications, and/or datastore content have been added
to the device. An administrator needs to be sure the access control
rules are correct for the new content in this case. Mechanisms to
detect NETCONF capability changes on a specific device are outside
the scope of this document.
It is possible that the data model definition itself (e.g., YANG It is possible that the data model definition itself (e.g., YANG
when-stmt) will help an unauthorized session determine the presence when-stmt) will help an unauthorized session determine the presence
or even value of sensitive data nodes by examining the presence and or even value of sensitive data nodes by examining the presence and
values of different data nodes. values of different data nodes.
There is a risk that non-standard protocol operations, or even the There is a risk that non-standard protocol operations, or even the
standard <get> protocol operation, may return data which "aliases" or standard <get> protocol operation, may return data which "aliases" or
"copies" sensitive data from a different data object. There may "copies" sensitive data from a different data object. There may
simply be multiple data model definitions which expose or even simply be multiple data model definitions which expose or even
configure the same underlying system instrumentation. configure the same underlying system instrumentation.
A data model may contain external keys (e.g., YANG leafref), which A data model may contain external keys (e.g., YANG leafref), which
expose values from a different data structure. An administrator expose values from a different data structure. An administrator
needs to be aware of sensitive data models which contain leafref needs to be aware of sensitive data models which contain leafref
nodes. This entails finding all the leafref objects that "point" at nodes. This entails finding all the leafref objects that "point" at
the sensitive data (i.e., "path-stmt" values that implicitly or the sensitive data (i.e., "path-stmt" values) that implicitly or
explicitly include the sensitive data node. explicitly include the sensitive data node.
It is beyond the scope of this document to define access control It is beyond the scope of this document to define access control
enforcement procedures for underlying device instrumentation that may enforcement procedures for underlying device instrumentation that may
exist to support the NETCONF server operation. An administrator can exist to support the NETCONF server operation. An administrator can
identify each protocol operation that the server provides, and decide identify each protocol operation that the server provides, and decide
if it needs any access control applied to it. if it needs any access control applied to it.
This document incorporates the optional use of a "recovery session" This document incorporates the optional use of a "recovery session"
mechanism, which can be used to bypass access control enforcement in mechanism, which can be used to bypass access control enforcement in
emergencies, such as NACM configuration errors which disable all emergencies, such as NACM configuration errors which disable all
access to the server. The configuration and identification of such a access to the server. The configuration and identification of such a
recovery session mechanism are implementation-specific and outside recovery session mechanism are implementation-specific and outside
the scope of this document. An administrator needs to be aware of the scope of this document. An administrator needs to be aware of
any "recovery session" mechanisms available on the device, and make any "recovery session" mechanisms available on the device, and make
sure they are used appropriately. sure they are used appropriately.
It is possible for a session to disrupt configuration management, It is possible for a session to disrupt configuration management,
even without any write access to the configuration, by locking the even without any write access to the configuration, by locking the
datastore. This may be done to insure all or part of the datastore. This may be done to insure all or part of the
configuration remains stable while it is being retrieved, ot it may configuration remains stable while it is being retrieved, or it may
be done as a "denial-of-service" attack. There is no way for the be done as a "denial-of-service" attack. There is no way for the
server to know the difference. An administrator may wish to restrict server to know the difference. An administrator may wish to restrict
"exec" access to the following protocol operations: "exec" access to the following protocol operations:
o <lock> o <lock>
o <unlock> o <unlock>
o <partial-lock> o <partial-lock>
skipping to change at page 47, line 36 skipping to change at page 49, line 36
<action>permit</action> <action>permit</action>
<comment> <comment>
Allow the limited and guest groups read Allow the limited and guest groups read
and update access to the dummy interface. and update access to the dummy interface.
</comment> </comment>
</rule> </rule>
</rule-list> </rule-list>
<rule-list> <rule-list>
<name>admin-acl</name> <name>admin-acl</name>
<group>admin</group>
<rule> <rule>
<name>permit-interface</name> <name>permit-interface</name>
<path xmlns:acme="http://example.com/ns/itf"> <path xmlns:acme="http://example.com/ns/itf">
/acme:interfaces/acme:interface /acme:interfaces/acme:interface
</path> </path>
<access-operations>*</access-operations> <access-operations>*</access-operations>
<action>permit</action> <action>permit</action>
<comment> <comment>
Allow admin full access to all acme interfaces. Allow admin full access to all acme interfaces.
</comment> </comment>
skipping to change at page 48, line 15 skipping to change at page 50, line 15
deny-nacm: This rule denies the "guest" group any access to the deny-nacm: This rule denies the "guest" group any access to the
<nacm> subtree. Note that the default namespace is only <nacm> subtree. Note that the default namespace is only
applicable because this subtree is defined in the same namespace applicable because this subtree is defined in the same namespace
as the <data-rule> element. as the <data-rule> element.
permit-acme-config: This rule gives the "limited" group read-write permit-acme-config: This rule gives the "limited" group read-write
access to the acme <config-parameters>. access to the acme <config-parameters>.
permit-dummy-interface: This rule gives the "limited" and "guest" permit-dummy-interface: This rule gives the "limited" and "guest"
groups read-update access to the acme <interface>. entry named groups read-update access to the acme <interface> entry named
"dummy". This entry cannot be created or deleted by these groups, "dummy". This entry cannot be created or deleted by these groups,
just altered. just altered.
permit-interface: This rule gives the "admin" group read-write permit-interface: This rule gives the "admin" group read-write
access to all acme <interface>. entries. This is an example of an access to all acme <interface> entries.
unreachable rule because the "mod-3" rule already gives the
"admin" group full access to this data.
A.5. Notification Rule Example A.5. Notification Rule Example
Notification rules are used to control access to a specific Notification rules are used to control access to a specific
notification event type. notification event type.
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
<rule-list> <rule-list>
<name>sys-acl</name> <name>sys-acl</name>
<group>limited</group> <group>limited</group>
skipping to change at page 49, line 4 skipping to change at page 50, line 46
<notification-name>sys-config-change</notification-name> <notification-name>sys-config-change</notification-name>
<access-operations>read</access-operations> <access-operations>read</access-operations>
<action>deny</action> <action>deny</action>
<comment> <comment>
Do not allow the guest or limited groups Do not allow the guest or limited groups
to receive config change events. to receive config change events.
</comment> </comment>
</rule> </rule>
</rule-list> </rule-list>
</nacm> </nacm>
This example shows 1 notification rule: This example shows 1 notification rule:
deny-config-change: This rule prevents the "limited" or "guest" deny-config-change: This rule prevents the "limited" or "guest"
groups from receiving the acme <sys-config-change> event type. groups from receiving the acme <sys-config-change> event type.
Appendix B. Change Log Appendix B. Change Log
-- RFC Ed.: remove this section before publication. -- RFC Ed.: remove this section before publication.
B.1. 04-05 B.1. 05-06
Added clarification to Security Considerations section about
ordered-by user lists (/nacm/rule-list and /nacm/rule-list/rule).
Added clarifications to security considerations wrt/ user names and
NETCONF capability changes.
Fixed typos found in review.
B.2. 04-05
Updated Security Considerations section. Updated Security Considerations section.
Changed term 'operator' to 'administrator'. Changed term 'operator' to 'administrator'.
Used the terms "access operation" and "protocol operation" Used the terms "access operation" and "protocol operation"
consistently. consistently.
Moved some normative text from section 2 to section 3. Also made it Moved some normative text from section 2 to section 3. Also made it
more clear that section 2 is not a requirements section, but more clear that section 2 is not a requirements section, but
documentation of the objectives for NACM. documentation of the objectives for NACM.
Renamed "nacm:secure" to "nacm:default-deny-write", and "nacm:very- Renamed "nacm:secure" to "nacm:default-deny-write", and "nacm:very-
secure" to "nacm:default-deny-all". Explained that "nacm:default- secure" to "nacm:default-deny-all". Explained that "nacm:default-
deny-write" is ignored on rpc statements. deny-write" is ignored on rpc statements.
Described that <kill-session> and <delete-config> behave as if Described that <kill-session> and <delete-config> behave as if
specified with "nacm:default-deny-all". specified with "nacm:default-deny-all".
B.2. 03-04 B.3. 03-04
Introduced rule-lists to group related rules together. Introduced rule-lists to group related rules together.
Moved "module-rule", "rpc-rule", "notification-rule", and "data-rule" Moved "module-rule", "rpc-rule", "notification-rule", and "data-rule"
into one common "rule", with a choice to select between the four into one common "rule", with a choice to select between the four
variants. variants.
Changed "superuser" to "recovery session", and adjusted text Changed "superuser" to "recovery session", and adjusted text
throughout document for this change. throughout document for this change.
Clarified behavior of global default NACM parameters, enable-nacm, Clarified behavior of global default NACM parameters, enable-nacm,
read-default, write-default, exec-default. read-default, write-default, exec-default.
Clarified when access control is applied during system Clarified when access control is applied during system
initialization. initialization.
B.3. 02-03 B.4. 02-03
Fixed improper usage of RFC 2119 keywords. Fixed improper usage of RFC 2119 keywords.
Changed term usage of "database" to "datastore". Changed term usage of "database" to "datastore".
Clarified that "secure" and "very-secure" extensions only apply if Clarified that "secure" and "very-secure" extensions only apply if
the /nacm/enable-nacm object is "true". the /nacm/enable-nacm object is "true".
B.4. 01-02 B.5. 01-02
Removed authentication text and objects. Removed authentication text and objects.
Changed module name from ietf-nacm to ietf-netconf-acm. Changed module name from ietf-nacm to ietf-netconf-acm.
Updated NETCONF and YANG terminology. Updated NETCONF and YANG terminology.
Removed open issues section. Removed open issues section.
Changed some must to MUST in requirements section. Changed some must to MUST in requirements section.
B.5. 00-01 B.6. 00-01
Updated YANG anf YANG Types references. Updated YANG anf YANG Types references.
Updated module namespace URI to standard format. Updated module namespace URI to standard format.
Updated module header meta-data to standard format. Updated module header meta-data to standard format.
Filled in IANA section. Filled in IANA section.
B.6. 00 B.7. 00
Initial version cloned from Initial version cloned from
draft-bierman-netconf-access-control-02.txt. draft-bierman-netconf-access-control-02.txt.
Authors' Addresses Authors' Addresses
Andy Bierman Andy Bierman
Brocade Brocade
Email: andy.bierman@brocade.com Email: andy.bierman@brocade.com
 End of changes. 33 change blocks. 
67 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/