Internet Draft Access Control MIB for SNMPv2 Aug 1995 Access Control MIB for Version 2 of the Simple Network Management Protocol (SNMPv2) 1 Aug 1995 draft-ietf-snmpv2-control-mib-00.txt David Harrington Cabletron Systems, Inc. dbh@ctron.com Sandeep Asija Cabletron Systems, Inc. asija@ctron.com Daniel O. Mahoney II Cabletron Systems, Inc. dmahoney@ctron.com David Arneson Cabletron Systems, Inc. arneson@ctron.com Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes and defines a portion of the Management Information Base (MIB) for use with the Simple Network Management Protocol version 2. In particular, it defines objects for specifying access to data and protocol operations for specified security entities. The method of applying access control is dependent on the security model in use, but the specification of access policy is security model independent. Expires January 1996 [Page 1] Internet Draft Access Control MIB for SNMPv2 Aug 1995 1. Introduction A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. The model described here is largely derived from the work of the SNMPv2 Working Group, as published in RFC1445 and RFC1447, and subsequent internet drafts. The administrative model described in those RFCs and drafts was determined to be inappropriate for some users, especially the required security framework. It is the purpose of this document, the Access Control MIB for SNMPv2, to define how access control entries can be applied to realize effective control of managed data in a variety of configurations and environments in a model which can be used with a variety of security frameworks, commonly referred to as admin models. It is the purpose of this document to define the properties associated with SNMPv2 access control filters, and to define managed objects which correspond to those properties, and to do so without dependence on a specific security or admin model. 1.1 Acknowledgements Much of this document was taken directly from the draft of the SNMPv2 Working Group published draft, draft-ietf-snmpv2-party-ds-02.txt, authored by Jeffrey D. Case, James Galvin, Keith McCloghrie, Marshall T. Rose, and Steven Waldbusser. The authors wish to acknowledge the contributions of the SNMPv2 Working Group in general. Harrington [Page 2] Internet Draft Access Control MIB for SNMPv2 Aug 1995 1.2. A Note on Terminology For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). 2. Overview For security reasons, it is valuable to restrict the operations allowed on the management information within a particular context for a particular security entity or entities. For example, one management application might be allowed to only read the values of objects, another may be allowed to modify the values of some objects, a third may be authorized to send informs to another manager, and a fourth may be authorized to be sent a notification (trap) in response to unusual events. 2.1. Authorization: Access Control An SNMPv2 message is associated with a datafilter and may be associated with zero or more security entities. The datafilter determines the set of management information being accessed by the message, and the security entities are used for applying access control policies. Access control is specified as a set of local access entries, where each entry is a combination of datafilter and security entities against which to compare a received message. The method of specifying and comparing the security entities is dependent on the admin model. Each access control entry specifies the set of operations which are allowed to be performed on the data by the security entities. If the datafilter or the security entities specified by the received message are not a valid combination, or the operation requested is not one of the operations allowed for the combination, then the requested access is denied. 2.2. SNMPv2 Access Control Policy An SNMPv2 access control policy is a specification of zero or more security entities and a local datafilter. The access policy specifies the authorized types of SNMPv2 operations for the security entities when accessing the objects contained in the management information subset specified by the context and MIB views referenced by the datafilter. Each such access control entry, called an ACL (for historical reasons), includes the following attributes: accDataFilterIdentity - the datafilterIdentity which identifies the management information subset on which requested management operations are to be performed, including which context contains the information, and which views are authorized for read-based or write-based operations. accSecurityModel - the security model to use to interpret accSecurityIdentity Harrington [Page 3] Internet Draft Access Control MIB for SNMPv2 Aug 1995 accSecurityIdentity - An admin-model specific formatted octet string containing information required to determine the security entities against which to apply access control policy. The interpretation of this octet string is defined by the admin model. accPrivileges - the types of SNMPv2 operations on the particular data subset that are authorized for SNMPv2 messages for the specified security entities. An SNMPv2 entity's LCD includes information on all ACLs containing local access control policies. An SNMPv2 manager may also include remote ACLs in its LCD in order to determine which operations are authorized by particular security entities for a particular remote context. The application of SNMPv2 access control policy is performed: o on receipt of GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations; and o prior to transmission of SNMPv2-Trap and Inform operations (the procedures by which this access-control is performed are specified in [3], and in the protocol documents for the selected security model). Note that application of SNMPv2 access control policy is never performed for Response nor Report operations. 2.3. Maintenance Function ACL An ACL entry for use with maintenance functions shall be defined by the admin model, if the admin model requires the use of maintenance functions. 3. Definitions SNMPv2-ACCESS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; Harrington [Page 4] Internet Draft Access Control MIB for SNMPv2 Aug 1995 accessMIB MODULE-IDENTITY LAST-UPDATED "9503190000Z" ORGANIZATION "IETF SNMPv2 Working Group" CONTACT-INFO " David Harrington Postal: Cabletron Systems Inc. ATTN: David Harrington Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 USA Phone: +1 603 337 7357 Email: dbh@ctron.com" DESCRIPTION "The MIB module describing SNMPv2 access control structures." REVISION "9508010000Z" DESCRIPTION "The initial revision of the MIB module from which this is derived was published as RFC 1447." ::= { snmpModules xxxx } -- textual conventions AccessPrivileges ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of access privileges which specify the authorized set of management operations permitted on the associated management information. These privileges are specified as a sum of values, where each value specifies a SNMPv2 PDU type by which an operation may be requested. The value for a particular PDU type is computed as 2 raised to the value of the ASN.1 context-specific tag for the appropriate SNMPv2 PDU type. The values (for the tags defined in [3]) are: Get : 1 GetNext : 2 (unused : 4) Set : 8 (unused : 16) GetBulk : 32 Inform : 64 SNMPv2-Trap : 128 The null set is represented by the value zero." SYNTAX INTEGER (0..255) Harrington [Page 5] Internet Draft Access Control MIB for SNMPv2 Aug 1995 -- administrative assignments accessAdmin OBJECT IDENTIFIER ::= { accessMIB 1 } -- object assignments accessMIBObjects OBJECT IDENTIFIER ::= { accessMIB 2 } -- SNMPv2 access privileges snmpAccess OBJECT IDENTIFIER ::= { accessMIBObjects 3 } accTable OBJECT-TYPE SYNTAX SEQUENCE OF AccEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The access privileges database." ::= { snmpAccess 2 } accEntry OBJECT-TYPE SYNTAX AccEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each conceptual row in this table represents an individual access policy, called an ACL (for historical reasons). An ACL specifies the access privileges authorized for communication via accSecurityIdentity concerning information delimited by a particular SNMPv2 datafilter. For each conceptual row in this table which is retained across a re-initialization of the entity's network management system, the combination of the accSecurityIdentity values of the referenced entities and the accDataFilterIdentity value of the referenced data must be the same after the re-initialization as it was before the re-initialization, even if the values of accSecurityIdentity and accDataFilterIdentity vary." INDEX { accDataFilterIdentity, accSecurityModel, accSecurityIdentity } ::= { accTable 1 } Harrington [Page 6] Internet Draft Access Control MIB for SNMPv2 Aug 1995 AccEntry ::= SEQUENCE { accDataFilterIdentity OBJECT IDENTIFIER, accSecurityModel INTEGER, accSecurityIdentity OCTET STRING, accPrivileges AccessPrivileges, accStorageType StorageType, accStatus RowStatus } accDataFilterIdentity OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this instance identifies the SNMPv2 datafilter associated with a particular set of access privileges." ::= { accEntry 1 } accSecurityModel OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The security model to use to interpret accSecurityIdentity." ::= { accEntry 2 } accSecurityIdentity OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..128)) MAX-ACCESS read-create STATUS current DESCRIPTION "Admin-model specific information for identifying a security entity or entities for which access control will be applied relative to the data described by the accDataFilterIdentity. The format of accSecurityIdentity and the interpretation of the value of accSecurityIdentity shall be specified by the admin model identified in accSecurityModel." ::= { accEntry 4 } accPrivileges OBJECT-TYPE SYNTAX AccessPrivileges MAX-ACCESS read-create STATUS current DESCRIPTION "The access privileges authorized for communication concerning the managed information contained in the particular subset of SNMPv2 data identified by accDataFilterIdentity." DEFVAL { 35 } -- Get, Get-Next & Get-Bulk ::= { accEntry 5 } Harrington [Page 7] Internet Draft Access Control MIB for SNMPv2 Aug 1995 accStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the accTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row." DEFVAL { nonVolatile } ::= { accEntry 6 } accStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the accTable. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of accStatus for that row. A conceptual row in this table is not qualified for activation until the context it references is active. A conceptual row in this table is immediately made notInService whenever the status of the context it references is made notInService. A conceptual row in this table is immediately destroyed whenever the context it references is destroyed. A conceptual row in this table is not qualified for activation until the security entities it references are active. A conceptual row in this table is immediately made notInService whenever the status of the security entities it references are made notInService. A conceptual row in this table is immediately destroyed whenever the security entities it references are destroyed." ::= { accEntry 7 } -- conformance information accessMIBConformance OBJECT IDENTIFIER ::= { accessMIB 3 } accessMIBCompliances OBJECT IDENTIFIER ::= { accessMIBConformance 1 } accessMIBGroups OBJECT IDENTIFIER ::= { accessMIBConformance 2 } Harrington [Page 8] Internet Draft Access Control MIB for SNMPv2 Aug 1995 -- compliance statements accessCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Access MIB." MODULE -- this module MANDATORY-GROUPS { accessMIBGroup } ::= { accessMIBCompliances 1 } -- units of conformance accessMIBGroup OBJECT-GROUP OBJECTS { accSecurityIdentity, accPrivileges, accStorageType, accStatus } STATUS current DESCRIPTION "The collection of objects allowing the description and configuration of SNMPv2 access control entries." ::= { accessMIBGroups 1 } 4. Usage Examples 4.1. Party-based Security Model Agent Configuration This section presents an example configuration for a SNMPv2 agent using a party-based security model. Table 1 presents information about the local access policy known by the agent and by the manager. accEntry: SecurityModel: <999> SecurityIdentity: DataFilterIdentity: df_device5 Privileges: Get/GetNext/GetBulk/SNMPv2-Trap DataFilter: Context: device5 ReadView: all WriteView: empty Table 1: Access Information for a sample party-based model Suppose that the SNMPv2 manager wishes to interrogate management information about the SNMPv2 datafilter named "df_device5", by issuing an SNMPv2 GetNext request message. The manager consults its LCD to discover that management information for datafilter "df_device5" is available using security model #999, using an agent party named gracie, and managing party george to access that datafilter. Harrington [Page 9] Internet Draft Access Control MIB for SNMPv2 Aug 1995 The manager assembles, serializes, and transmits the request according to security model. The agent receives the message, and processes the security according to the requirements of the security model. The received message is processed only if the agent's access control method for security model #999 authorizes GetNext request operations by the specified security entities with respect to the datafilter "df_device5". During the processing of the received request, each specified item of management information is accessed only as authorized by the relevant MIB view. 4.2. User-based Security Model Agent Configuration This section presents an example configuration for a SNMPv2 agent using a user-based security model. Table 2 presents information about the local access policy known by the agent and by the manager. accEntry: SecurityModel: <300> SecurityIdentity: DataFilterIdentity: df_device5 Privileges: Get/GetNext/GetBulk/Set/SNMPv2-Trap DataFilter: Context: device5 ReadView: all WriteView: 17 Table 2: User-based Security Model Access Information Suppose that the SNMPv2 manager wishes to modify management information in the SNMPv2 datafilter named "df_device5", by issuing an SNMPv2 Set request message. The manager consults its LCD to discover that management information for datafilter "df_device5" is writable through the agent's user named ollie operating under security model #300 to access that datafilter. If the manager chooses to maintain a copy of remote views in its LCD, it can verify that the objects to be written are within the constraints of the remote view #17 within context "device5" before proceeding. The manager assembles, serializes, and transmits the request according to security model. The agent receives the message, and processes the security according to the requirements of the security model. The received message is processed only if the agent's access control method for security model #300 authorizes Set request operations by user "ollie" with respect to the datafilter "df_device5". During the processing of the received request, each specified item of management information is accessed only as authorized by the relevant MIB view. Harrington [Page 10] Internet Draft Access Control MIB for SNMPv2 Aug 1995 4.3. Community-based Security Model Agent Configuration This section presents an example configuration for a SNMPv2 agent using a community-based authentication model [4]. Table 3 presents information about the local access policy known by the agent and by the manager. accEntry: SecurityModel: <123> SecurityIdentity: DataFilterIdentity: df_device5 Privileges: Get/GetNext/GetBulk/Set/SNMPv2-Trap DataFilter: Context: "private" ReadView: all WriteView: all Table 3: Community-based Security Model Access Information Suppose that the SNMPv2 manager wishes to modify management information in the SNMPv2 datafilter named "df_device5", by issuing an SNMPv2 Set request message. The manager consults its LCD to discover that management information for datafilter "df_device5" is writable through the agent's community string "private" under security model #123 to access that datafilter. The manager assembles, serializes, and transmits the request according to security model. The agent receives the message, and processes the security according to the requirements of the security model. The received message is processed only if the agent's access control method for security model #123 authorizes Set request operations by community "private" with respect to the datafilter "df_device5". During the processing of the received request, each specified item of management information is accessed only as authorized by the relevant MIB view. 5. References [1] Information processing systems - Open Systems Interconnection Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, May 1995. Harrington [Page 11] Internet Draft Access Control MIB for SNMPv2 Aug 1995 [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, May 1995. [4] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. 6. Security Considerations In order to participate in the administrative model set forth in this memo, SNMPv2 implementations must support local, non-volatile storage of the LCD. Accordingly, every attempt has been made to minimize the amount of non-volatile storage required. 7. Authors' Addresses Daniel O. Mahoney II Cabletron Systems, Inc. ATTN: Dan Mahoney Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 US Phone: +1 603 337 7355 Email: dmahoney@ctron.com Sandeep Asija Cabletron Systems, Inc. ATTN: Sandeep Asija Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 US Phone: +1 603 337 7185 Email: asija@ctron.com David Harrington Cabletron Systems, Inc. ATTN: David Harrington Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 US Harrington [Page 12] Internet Draft Access Control MIB for SNMPv2 Aug 1995 Phone: +1 603 337 7357 Email: dbh@ctron.com David Arneson Cabletron Systems, Inc. ATTN: David Arneson Engineering - Merrimack P.O. Box 5005 Rochester NH 03866-5005 US Phone: +1 603 337 5238 Email: arneson@ctron.com Harrington [Page 13] Internet Draft Access Control MIB for SNMPv2 Aug 1995 Table of Contents 1 Introduction .................................................... 2 1.1 Acknowledgements .............................................. 2 1.2 A Note on Terminology ......................................... 3 2 Overview ........................................................ 3 2.1 Authorization ................................................. 3 2.2 SNMPv2 Access Control Policy .................................. 4 2.3 Maintenance Function ACL ...................................... 4 3 Definitions ..................................................... 4 4 Usage Examples .................................................. 9 4.1 Party-based Security Model Agent Configuration ................ 9 4.2 User-based Security Model Agent Configuration ................. 10 4.3 Community-based Security Model Agent Configuration ............ 11 5 References ...................................................... 11 6 Security Considerations ......................................... 12 7 Authors' Addresses .............................................. 12 Expires January 1996 [Page 14]