--- 1/draft-ietf-netconf-access-control-00.txt 2010-10-25 23:14:26.000000000 +0200 +++ 2/draft-ietf-netconf-access-control-01.txt 2010-10-25 23:14:26.000000000 +0200 @@ -1,19 +1,19 @@ Internet Engineering Task Force A. Bierman Internet-Draft Brocade Intended status: Standards Track M. Bjorklund -Expires: March 6, 2011 Tail-f Systems - September 2, 2010 +Expires: April 28, 2011 Tail-f Systems + October 25, 2010 Network Configuration Protocol Access Control Model - draft-ietf-netconf-access-control-00 + draft-ietf-netconf-access-control-01 Abstract The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment, which promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF operations and content. This document discusses requirements for a suitable access control @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 6, 2011. + This Internet-Draft will expire on April 28, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -109,33 +109,34 @@ 5.3.2. Session Establishment . . . . . . . . . . . . . . . . 24 5.3.3. 'access-denied' Error Handling . . . . . . . . . . . . 24 5.3.4. Incoming RPC Message Validation . . . . . . . . . . . 24 5.3.5. Data Node Access Validation . . . . . . . . . . . . . 27 5.3.6. Outgoing Authorization . . . . . . . . . . 29 5.3.7. Outgoing Authorization . . . . . . . . 30 5.4. Data Model Definitions . . . . . . . . . . . . . . . . . . 33 5.4.1. High Level Procedures . . . . . . . . . . . . . . . . 33 5.4.2. Data Organization . . . . . . . . . . . . . . . . . . 33 5.4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 34 - 5.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 49 - 5.6. Security Considerations . . . . . . . . . . . . . . . . . 49 - 6. Normative References . . . . . . . . . . . . . . . . . . . . . 51 - Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 52 - A.1. Example . . . . . . . . . . . . . . . . . . . . . 52 - A.2. Example . . . . . . . . . . . . . . . . . . 53 - A.3. Example . . . . . . . . . . . . . . . . . . . . 54 - A.4. Example . . . . . . . . . . . . . . . . . . . 56 - A.5. Example . . . . . . . . . . . . . . . 58 - Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 59 - Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 60 - C.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 + 5.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 50 + 5.6. Security Considerations . . . . . . . . . . . . . . . . . 50 + 6. Normative References . . . . . . . . . . . . . . . . . . . . . 52 + Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 53 + A.1. Example . . . . . . . . . . . . . . . . . . . . . 53 + A.2. Example . . . . . . . . . . . . . . . . . . 54 + A.3. Example . . . . . . . . . . . . . . . . . . . . 55 + A.4. Example . . . . . . . . . . . . . . . . . . . 57 + A.5. Example . . . . . . . . . . . . . . . 59 + Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 60 + Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 61 + C.1. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 61 + C.2. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 1. Introduction The NETCONF protocol does not provide any standard mechanisms to restrict the operations and content that each user is authorized to use. There is a need for inter-operable management of the controlled access to operator selected portions of the available NETCONF content within a particular server. @@ -145,21 +146,21 @@ in [RFC4741], and [RFC5277]. It contains five main sections: 1. Authentication Requirements 2. Access Control Requirements 3. NETCONF Authentication and Authorization Model 4. NETCONF Access Control Model (NACM) - 5. YANG Data Model (nacm.yang) + 5. YANG Data Model (ietf-nacm.yang) 1.1. Terminology 1.1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1.2. NETCONF Terms @@ -714,24 +715,24 @@ 5.1.2. External Dependencies The NETCONF [RFC4741] protocol is used for all management purposes within this document. The server must support the features identified by the 'NETCONF-base' capability. It is expected that the mandatory transport mapping NETCONF Over SSH [RFC4742] is also supported by the server, and that the server has access to the user name associated with each session. - The YANG Data Modeling Language [I-D.ietf-netmod-yang] is used to - define the NETCONF data models specified in this document. The YANG - instance-identifier data type can be used to configure data-node- - specific access control rules. + The YANG Data Modeling Language [RFC6020] is used to define the + NETCONF data models specified in this document. The YANG instance- + identifier data type can be used to configure data-node-specific + access control rules. 5.1.3. Message Processing Model The following diagram shows the NETCONF message flow model, including the points at which access control is applied, during NETCONF message processing. +-------------------------+ | session | | (username) | @@ -1387,49 +1388,86 @@ configuration database access. list : Configures the access control rules for controlling delivery of events. 5.4.3. YANG Module The following YANG module is provided to specify the normative NETCONF content that must by supported by the server. - file="nacm@2010-06-29.yang" + The ietf-nacm YANG module imports typedefs from [RFC6021]. - module nacm { + // RFC Ed.: please update the date to the date of publication + file="ietf-nacm@2010-10-25.yang" + + module ietf-nacm { + + namespace "urn:ietf:params:xml:ns:yang:ietf-nacm"; - namespace "file://draft-bierman-netconf-access-control-02.txt"; prefix "nacm"; import ietf-yang-types { prefix yang; + } import ietf-inet-types { prefix inet; - } organization - "IETF"; + "IETF NETCONF (Network Configuration) Working Group"; contact - "Andy Bierman - Martin Bjorklund "; + "WG Web: + WG List: + + WG Chair: Mehmet Ersue + + + WG Chair: Bert Wijnen + + + Editor: Andy Bierman + + + Editor: Martin Bjorklund + "; description - "NETCONF Server Access Control Model"; + "NETCONF Server Access Control Model. - revision 2010-09-02 { + Copyright (c) 2010 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Simplified BSD + License set forth in Section 4.c of the IETF Trust's + Legal Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC XXX; see + the RFC itself for full legal notices."; + // RFC Ed.: replace XXXX with actual RFC number and remove this note + + //reference "RFC XXXX"; + + // RFC Ed.: remove this note + // Note: extracted from draft-ietf-netconf-access-control-01.txt + // RFC Ed.: please update the date to the date of publication + revision "2010-10-25" { description - "Initial version (work-in-progress)."; + "Initial version"; + reference + "RFC XXXX: Network Configuration Protocol Access Control Model"; } /* * Extension statements */ extension secure { description "Used to indicate that the data model node represents a sensitive security system parameter. @@ -1580,21 +1618,21 @@ "NETCONF Access Rights. The string '*' indicates that all possible access rights apply to the access rule. Otherwise, only the specific access rights represented by the bit names that are present apply to the access rule."; } typedef nacm-group-name-type { type string { length "1..max"; - pattern "~\*[.*]"; + pattern "[^\*].*"; } description "Name of administrative group that can be assigned to the user, and specified in an access control rule."; } typedef nacm-action-type { type enumeration { enum permit { @@ -1627,22 +1665,22 @@ This XPath expression is evaluated in the following context: o The set of namespace declarations are those in scope on the leaf element where this type is used. o The set of variable bindings contains one variable, 'USER', which contains the name of user of the current session. - o The function library is the core function library, but note - that due to the syntax restrictions of an + o The function library is the core function library, but + note that due to the syntax restrictions of an instance-identifier, no functions are allowed. o The context node is the root node in the data tree."; } typedef md5-crypt { type string { pattern "$0$.* | $1$[a-zA-Z0-9./]{2,8}$.*"; } description @@ -2073,37 +2112,50 @@ description "Name of the module defining this notification event type."; } leaf notification-name { type string; description "Name of the notification event."; } + uses common-rule-parms; } } } } - Figure 5 5.5. IANA Considerations - There are two actions that are requested of IANA: + There are two actions that are requested of IANA: This document + registers one URI in "The IETF XML Registry". Following the format + in [RFC3688], the following has been registered. - 1. register data model schema namespace URI (TBD) + URI: urn:ietf:params:xml:ns:yang:ietf-nacm + Registrant Contact: The IESG. + XML: N/A, the requested URI is an XML namespace. - 2. register data model name ('nacm') + This document registers one module in the "YANG Module Names" + registry. Following the format in [RFC6020], the following has been + registered. + + name: ietf-nacm + namespace: urn:ietf:params:xml:ns:yang:ietf-nacm + prefix: nacm + reference: RFC XXXX + // RFC Ed.: Replace XXX with actual RFC number + // and remove this note 5.6. Security Considerations This entire document discusses access control requirements and mechanisms for restricting NETCONF protocol behavior within a given session. Configuration of the access control system is highly sensitive to system security. A server may choose not to allow any user configuration to some portions of it, such as the global security @@ -2167,70 +2219,70 @@ 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009. + [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the + Network Configuration Protocol (NETCONF)", RFC 6020, + October 2010. + + [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, + October 2010. + [W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- xml, October 2000, . - [I-D.ietf-netmod-yang] - Bjorklund, M., "YANG - A data modeling language for the - Network Configuration Protocol (NETCONF)", - draft-ietf-netmod-yang-13 (work in progress), June 2010. - - [I-D.ietf-netmod-yang-types] - Schoenwaelder, J., "Common YANG Data Types", - draft-ietf-netmod-yang-types-09 (work in progress), - April 2010. - Appendix A. Usage Examples The following XML snippets are provided as examples only, to demonstrate how NACM can be configured to perform some access control tasks. A.1. Example There must be at least one entry in order for any of the access control rules to be useful. The following XML shows arbitrary groups, and is not intended to represent any particular use-case. - + admin admin andy monitor wilma @@ -2255,21 +2307,21 @@ 3. The nacm:guest group contains 2 users named 'guest' and 'guest@example.com'. A.2. Example Module rules are used to control access to all the content defined in a specific module. These rules are checked after none of the specific rules (i.e., rpc-rule, data-rule, or notification-rule) matched the current access request. - + ietf-netconf-monitoring mod-1 * guest deny Do not allow guests any access to the netconf monitoring information. @@ -2326,21 +2378,21 @@ operation supported by the server. mod-4: This rule allows the admin group complete access to all content in the server. No subsequent rule will match for the admin group, because of this module rule. A.3. Example RPC rules are used to control access to a specific RPC operation. - + ietf-netconf kill-session rpc-1 monitor guest deny Do not allow the monitor or guest group @@ -2384,21 +2436,21 @@ rpc-3: This rule allows the monitor group to invoke the NETCONF RPC operation. This rule will have no real affect unless the 'exec-default' leaf is set to 'deny'. A.4. Example Data rules are used to control access to specific (config and non- config) data nodes within the NETCONF content provided by the server. - + data-1 /nacm * guest deny Deny the guest group any access to the /nacm data. @@ -2472,21 +2524,21 @@ admin-itf: This rule gives the admin group read-write access to all acme . entries. This is an example of an unreachable rule because the 'mod-3' rule already gives the admin group full access to this data. A.5. Example Notification rules are used to control access to a specific notification event type. - + acme-system sys-config-change notif-1 monitor guest deny Do not allow the guest or monitor groups @@ -2534,21 +2586,31 @@ 9. Should the default access levels (e.g., read-default) be more restrictive by default? Shiuld these defaults be a vendor decision? An operator decision? It is important that the server be able to install a factory default container if needed. Appendix C. Change Log -- RFC Ed.: remove this section before publication. -C.1. 00 +C.1. 00-01 + + Updated YANG anf YANG Types references. + + Updated module namespace URI to standard format. + + Updated module header meta-data to standard format. + + Filled in IANA section. + +C.2. 00 Initial version cloned from draft-bierman-netconf-access-control-02.txt. Authors' Addresses Andy Bierman Brocade Email: andy.bierman@brocade.com