Network Working Group K. Narayan Internet-Draft Cisco Systems, Inc. Intended status: Standards Track D. Nelson Expires: January 6, 2010 Elbrys Networks, Inc. July 5, 2009 Extensions to View-based Access Control Model for use with RADIUS draft-nelson-isms-extended-vacm-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo describes a backward compatible extension to the View-based Access Control Model for SNMPv3 for use with RADIUS and other AAA Narayan & Nelson Expires January 6, 2010 [Page 1] Internet-Draft Extended VACM July 2009 services to provide authorization of MIB database access. This extension is intended to be used in conjunction with secure SNMP Transport Models that facilitate RADIUS authentication, such as the Secure Shell Transport Model. Requirements Language 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. System Block Diagram . . . . . . . . . . . . . . . . . . . 3 1.3. Using RADIUS with SNMP . . . . . . . . . . . . . . . . . . 4 2. RADIUS Authorization for Extended VACM . . . . . . . . . . . . 5 3. VACM Extension . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Elements of the tmStateReference . . . . . . . . . . . . . 6 3.2. Dynamic Update of Extended VACM MIB Module Objects . . . . 6 3.3. Purging Volatile Entries in the Extended VACM MIB Module . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Narayan & Nelson Expires January 6, 2010 [Page 2] Internet-Draft Extended VACM July 2009 1. Introduction 1.1. General The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the Security Subsystem. Transport Subsystem for the Simple Network Management Protocol [RFC5590] defines a Transport Subsystem, Transport Security Model for SNMP [RFC5591] a new Transport Security Model, Secure Shell Transport Model for SNMP [RFC5592] a Secure Shell Transport Model and Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models [I-D.ietf-isms-radius-usage] a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the SSH transport. This document builds on that work and describes a means to centrally authorize a given SNMP transaction using on-device, pre-existing authorization configuration. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. This document defines an extension to obtain authorization information for an authenticated principal, from RADIUS. Additional introductory material on the RADIUS operational model and RADIUS usage with SNMP may be found in Sections 1.3 and 1.5 of [I-D.ietf-isms-radius-usage]. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the Extended View-based Access Control Model described in this memo fits into the architecture and interacts with other subsystems and models within the architecture. It is expected that reader will have also read and understood RFC3411 [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], RFC3415 [RFC3415]and RFC3418 [RFC3418]. 1.2. System Block Diagram A block diagram of the major system components referenced in this document may be useful to understanding the text that follows. Narayan & Nelson Expires January 6, 2010 [Page 3] Internet-Draft Extended VACM July 2009 +--------+ +......................... |RADIUS |....+ . |Server | . Shared +--------+ . User | . Credentials RADIUS | Shared . | RADIUS . | Secret . | . +-------------+ +-----------------+ | Network | | RADIUS Client / | | Management | SNMP | SNMP Engine / | | Application |------------------| Network Device | +-------------+ SSH +-----------------+ Block Diagram This diagram illustrates that a network management application communicates with a network device, the managed entity, using SNMP over SSH. The network devices uses RADIUS to communicate with a RADIUS Server to authenticate the network management application (or the user whose credentials that application provides) and to obtain authorization information related to access via SNMP for purpose of device management. Other secure transport protocols might be used instead of SSH. 1.3. Using RADIUS with SNMP There are two use cases for RADIUS support of management access via SNMP. These are (a) service authorization and (b) access control authorization. RADIUS almost always involves user authentication as prerequisite to authorization, and there is a user authentication phase for each of these two use cases. The first use case is discussed in detail in [I-D.ietf-isms-radius-usage]. The second use case is the subject of this document. This document describes how RADIUS attributes and messages are applied to the specific application area of SNMP Access Control Models. This document assumes that Extended VACM will be used in conjunction with an SNMP secure Transport Model and the SNMP Transport Security Model. The rationale for this assumption is as follows. The RFC 3411 SNMP architecture maintains strong modularity and separation of concerns, extending to separating user identity (authentication) from user database access rights (authorization). The former is the business of the Security Subsystem and the latter is the business of the Access Control Subsystem. RADIUS, on the other hand, allows for no such separation of authorization from authentication. In order to Narayan & Nelson Expires January 6, 2010 [Page 4] Internet-Draft Extended VACM July 2009 use RADIUS with SNMP, binding of user authentication to user authorization must be achieved, without violating the modularity of the RFC 3411 SNMP architecture. RADIUS does support a limited form of Authorize-Only operations. The RADIUS "Authorize Only" Service-Type Attribute can be specified in an Access-Request message, but only when accompanied by a RADIUS State Attribute, which contains an implementation specific "cookie" representing the successful outcome of a previous authentication transaction. For that reason, it is not possible to completely separate the use of RADIUS by the Access Control Subsystem from the use of RADIUS by other subsystems. This suggests that the most straightforward approach is to leverage the existing RADIUS usage, as documented in [I-D.ietf-isms-radius-usage], and the tmStateReference cache, as documented in Section 5.2 of [RFC5590]. This document also assumes that the detailed access control rules are pre-configued in the NAS. Dynamic user authorization for MIB database access control, as defined herein, is limited to mapping the authenticated user to a pre-existing group, which in turn is mapped to the pre-existing rules. The operative use case assumption is that roles within an organization (i.e. groups and rules) change infrequently while the users assigned to those roles change much more frequently. It is the user to role mapping that is outsourced to the RADIUS server. 2. RADIUS Authorization for Extended VACM This document will rely on implementation specific integration of the RADIUS client for user authentication and authorization. Further, it will rely on implementation specific caching of MIB database access policy information, in the form of the RADIUS Management-Policy-Id Attribute, such that it will be available to Extended VACM. A NAS that is compliant to this specification, MUST treat any RADIUS Access-Accept message that provisions a specific policy for MIB database access control that cannot be provided as if an Access- Reject message had been received instead. The RADIUS Management-Policy-Id Attribute MUST be used in an Access- Accept message to provision a user-specific access control policy for use in conjunction with Extended VACM. The syntax and semantics of the Management-Policy-Id attribute are described in Section 6.3 of [I-D.ietf-radext-management-authorization]. The intended use of the content of the Management-Policy-Id attribute is to provision a mapping between the authenticated user, associated Narayan & Nelson Expires January 6, 2010 [Page 5] Internet-Draft Extended VACM July 2009 with the secure transport session, and an access control group pre- provisioned in the VACM MIB module. Details of this mapping are described in following sections. 3. VACM Extension The extension to VACM [RFC3415] described in this document is a method for one or more of its MIB module objects to be provisioned based on information received from RADIUS, or some similar AAA service. This extension requires no changes to the Abstract Service Interface (ASI) for the Access Control Subsystem, nor any changes in the Elements of Procedure (EOP) for VACM. It does require that a module of code somewhere in the NAS be able to write to the VACM MIB module, and that it reliably and consistently do so in immediate response to access control policy information received from RADIUS. 3.1. Elements of the tmStateReference Elements of the tmStateReference are described in Section 5.2 of [RFC5590]. This document specifies an additional element within the group of elements related to Session Information ( see Section 5.2.4 of [RFC5590] ). The additional element is tmAccessPolicy. The syntax and semantics of this element are as follows: o tmAccessPolicy: this element is used by the Extended VACM (or some other, yet to be defined, tansport-aware Access Control Model) to provision the mapping of authenticated SNMP principal (securityName) to the groupName used for access control decisions in Extended VACM. The content of tmAccessPolicy is copied from the content of the RADIUS Management-Policy-Id Attribute contained in the RADIUS Access- Accept message that is associated with this session. The content of this element is a simple and monolithic name within a name-space of significance to the NAS. It is intended to be human readable and the contents MUST NOT be parsed by the NAS; the contents can only be used to look up locally defined policies. It is RECOMMENDED that the element contain UTF-8 encoded 10646 characters. 3.2. Dynamic Update of Extended VACM MIB Module Objects The VACM MIB Module [RFC3415] objects that need to be dynamically updated, from the tmAccessPolicy and tmSecurityName elements of the tmStateReference cache, are entries in the vacmSecurityToGroupTable table. The tmSecurityName becomes the vacmSecurityName and the tmAccessPolicy becomes the vacmGroupName. The vacmSecurityModel is the encoding for the Transport Security Model. The Narayan & Nelson Expires January 6, 2010 [Page 6] Internet-Draft Extended VACM July 2009 vacmSecurityToGroupStorageType should be (2) volatile. In creating a row entry in the vacmSecurityToGroupTable, there are three cases to consider: o No existing row has a matching vacmSecurityName. o An existing row has a matching vacmSecurityName. o No additional rows can be created, e.g. because of resource constraints, etc. The second and third cases require special consideration. The second case may represent a conflict between dynamic access control authorization from RADIUS and local access control configuration by a security administrator, e.g. via remote or local SNMP MIB updates. If one assumes that the security administrator intentionally configured a table entry for the "conflicting" securityName, with full knowledge that it might over-ride dynamic authorization information from RADIUS, the right thing to do would be nothing. That is to say, do not update the table based on RADIUS authorization information. On the other hand, it is possible that the "name collision" is the result of a mistake, or the result of stale configuration information. EDITOR'S NOTE: The WG needs to decide who wins these "name collisions", RADIUS or the local configuration datastore, and whether there are any potential security risks attendant to the decision. The third case is likely to be rare, and SHOULD result in a notification of some sort being logged for action by the system administrator. It is REQUIRED that the tmAccessPolicy name match an existing VACM groupName. If no matching VACM groupName exists, then the access control information obtained from RADIUS, via the tmStateReference, MUST be ignored and no entry created in the vacmSecurityToGroup table. In the absence of any previously configured, e.g. non- volatile, table entries this will result in the default access rights of "no access", which is the desired result. It would be useful to maintain a counter of these occurrences for troubleshooting purposes, as this most likely indicates an administrative misconfiguration. 3.3. Purging Volatile Entries in the Extended VACM MIB Module When the session associated with the tmStateReference is torn down, disconnected or times out, any volatile table rows created in the vacmSecurityToGroup table should be removed. The mechanism to accomplish this task is implementation specific. Narayan & Nelson Expires January 6, 2010 [Page 7] Internet-Draft Extended VACM July 2009 4. IANA Considerations This document makes no requests of IANA for new allocations. 5. Security Considerations This specification describes the use of RADIUS for purposes of authentication and authorization. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]. Additional security considerations for use of SNMP with secure Transport Models [RFC5590] and the Transport Security Model [RFC5591] are found in the Security Considerations sections of the respective documents. If the SNMPv1 or SNMPv2c Security Model is used, then securityName comes from the community name, as per RFC3584. If the User-based Security Model is selected, then securityName is determined using USM. This may not be what is expected when using an SNMP secure Transport Model with an external authentication service, such as RADIUS. Simultaneously using a secure transport with RADIUS authentication and authorization, and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED. See the coexistence section of [RFC5590]. There are good reasons to provision USM access to supplement with AAA-based access, however. When the network is under duress, or the AAA-service is unreachable, for any reason, it is important to have access credentials stored in the local configuration data-store of the managed entity. USM credentials are a likely way to fulfill this requirement. This is analogous to configuring a local "root" password in the "/etc/passwd" file of a UNIX workstation, to be used as a backup means of login, for times when the Network Information Service (NIS) authentication service is unreachable. The Message-Authenticator (80) attribute [RFC3579] SHOULD be used with RADIUS messages that are described in this memo. This is useful because the Message-Authenticator Attribute is the best available mechanism in RADIUS as it stands today to provide tamper-evident integrity protection of the service provisioning attributes in an Access-Accept packet. It is slightly less important for Access- Request packets, although it may be desirable to protect any "hint" attributes contained in those messages. This protection mitigates the fact that RADIUS messages are not encrypted and that attributes could be added, deleted or modified by an adversary in a position to Narayan & Nelson Expires January 6, 2010 [Page 8] Internet-Draft Extended VACM July 2009 intercept the packet. 6. References 6.1. Normative References [I-D.ietf-isms-radius-usage] Narayan, K. and D. Nelson, "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models", draft-ietf-isms-radius-usage-07 (work in progress), May 2009. [I-D.ietf-radext-management-authorization] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", draft-ietf-radext-management-authorization-07 (work in progress), May 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. 6.2. Informative References [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Narayan & Nelson Expires January 6, 2010 [Page 9] Internet-Draft Extended VACM July 2009 Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009. Authors' Addresses Kaushik Narayan Cisco Systems, Inc. 10 West Tasman Drive San Jose, CA 95134 USA Phone: +1.408.526.8168 Email: kaushik_narayan@yahoo.com David Nelson Elbrys Networks, Inc. 75 Rochester Ave, Unit #3, Portsmouth, NH 03801 USA Phone: +1.603.570.2636 Email: d.b.nelson@comcast.net Narayan & Nelson Expires January 6, 2010 [Page 10]