View-based Access Control Model for the Simple Network Management Protocol (SNMP) 14 July 1997 Bert Wijnen IBM T. J. Watson Research wijnen@vnet.ibm.com Randy Presuhn BMC Software, Inc. rpresuhn@bmc.com Keith McCloghrie Cisco Systems, Inc. kzm@cisco.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 the View-based Access Control Model (ACM) for use in the SNMP architecture [SNMP-ARCH]. It defines the Elements of Procedure for applying access control to management information. This document also includes a MIB for remotely managing the configuration parameters for this ACM. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 1] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 0. Issues and Change Log 0.1. Issues - acknowledgements needs expansion - There is a reverse mapping from groupName to securityName, see the acmGroupListTable. However, given the amount of object we're adding, we may want to remove/postpone this table? - reference section must be checked; sync up with other documents - Do we need/want the level of detail of errorIndication that the isAccessAllowed primitive will return? Those who strongly object to the details listed now, better let us know (on the mailing list preferably) ASAP. 0.2. Change Log [version 4.2] - This is the July 14 version. - Address comments by Keith: - Renumber section 2.4 to 2.5 - Add new sections 2.4, 2.4.1, 2.4.2 about MIB Views and Subtrees and Families, - Use some more precise language at various places. - Add reference to RFC2119 about use of SHOULD and MUST - rename the acmGroupTable to acmSecurityToGroupTable because that much better indicates the function of this table. - improved the writeup on statusInformation for the isAccessAllowed primitive. - paginate and generate table of contents - posted as I-D on 15 July [version 4.1] - This is the July 12 version. - Adapt to latest list of Primitives/Parameters. - Handle comments from co-editor Randy - Added the SHOULD "initial" configuration - Checked the MIB with SMICng [version 4.0] - This is the July 7 version. - Adopt to decisions/comments made are 2nd interim - securityName to groupName mapping is in ACM - out of the box configurations to be described as SHOULD - UTF-8 issue still open, but move to general issue (ARCH) where the SnmpAdminString is defined. - ACM returns errorIndication based on which the caller may increment error counter which may result in a Report PDU. - No statistics counters are kept in ACM - removed viewTable; added acmViewSpinLock - Address various comments from co-editors (Randy and Keith) - Address comments made on mailing list(s). [version 3.1] - This is the June 18 version. - remove old (resolved) issues Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 2] Draft View-based Access Control Model (ACM) for SNMP July 1997 - list new issues - corrections/additions by myself (Bert) - corrections based on dbh comments - removed change log of before 1st interim meeting. [version 3.0] - this is the first ACM doc (June 12 version). - Modifications as agreed at 1st Interim Meeting - Make Access Control Module a separate document - Use viewName as index instead of an integer - add notify_view - use SnmpAdminString - Other Modification - use miId and securityModel - add acmGroupTable - add/rename Stats counters Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 3] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 1. Introduction The Architecture for describing Internet Management Frameworks [SNMP-ARCH] is composed of multiple subsystems: 1) a Message Processing Subsystem, 2) a Security Subsystem, 3) an Access Control Subsystem, Applications make use of the services of these subsystems. It is important to understand the SNMP architecture and its terminology to understand where the View-based Access Control Model described in this document fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description and terminology of the SNMP architecture, as defined in [SNMP-ARCH]. The Access Control Subsystem of an SNMP engine provides services to determine whether access to an object instance is permitted. An Access Control Model has the responsibility for checking if a specific type of access (read, write, notify) to a particular object (instance) is allowed. It is the purpose of this document to define a specific model of the Access Control Subsystem, designated the View-based Access Control Model. 1.2. Access Control Access Control occurs (either implicitly or explicitly) in an SNMP entity when processing SNMP retrieval or modification request messages from another SNMP entity. For example a Command Responder application applies Access Control when processing requests that it received from a Command Generator application. These requests include these types of operations: GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations. Access Control also occurs in an SNMP entity when an SNMP notification message is generated (by a Notification Originator application). These notification messages include these types of operations: InformRequest and SNMPv2-trap operations. The View-based Access Control Model defines a set of services that an application (such as a Command Responder or a Notification Originator application) can use for checking access rights. It is the responsibility of the application to make the proper service calls for access checking. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 4] Draft View-based Access Control Model (ACM) for SNMP July 1997 1.3. Local Configuration Datastore To implement the model described in this document, an SNMP entity needs to retain information about access rights and policies. This information is part of the SNMP engine's Local Configuration Datastore (LCD). See [SNMP-ARCH] for the definition of LCD. In order to allow an SNMP entity's LCD to be remotely configured, portions of the LCD need to be accessible as managed objects. A MIB module, the View-based Access Control Model Configuration MIB, which defines these managed object types is included in this document. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 5] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 2. Elements of the Model This section contains definitions to realize the access control service provided by the View-based Access Control Model. 2.1. groupName A groupName identifies a group (set) of zero or more securityNames on whose behalf SNMP management objects can be accessed. A group defines the access rights afforded to all securityNames which belong to that group. The combination of a securityModel and a securityName maps to at most one group. The Access Control module assumes that the securityName has already been authenticated as needed and provides no further authentication of its own. The View-based Access Control Model uses the securityModel and the securityName as inputs to the Access Control module when called to check for access rights. It determines the groupName as a function of securityModel and securityName. 2.2. Level of Security (LoS) Different access rights for members of a group can be defined for different Levels of Security. The LoS identifies the Level of Security that will be assumed when checking for access rights. See the SNMP Architecture document [SNMP-ARCH] for a definition of LoS. The View-based Access Control Model requires the LoS to be passed as input to the Access Control module when called to check for access rights. 2.3. Contexts An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts. Details about the naming of management information can be found in the SNMP Architecture document [SNMP-ARCH]. The View-based Access Control Model defines an acmContextTable that lists the locally available contexts by contextName. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 6] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 2.4. MIB Views and View Families For security reasons, it is often valuable to be able to restrict the access rights of some groups to only a subset of the management information in the management domain. To provide this capability, access to a context is via a "MIB view" which details a specific set of managed object types (and optionally, the specific instances of object types) within that context. For example, for a given context, there will typically always be one MIB view which provides access to all management information in that context, and often there will be other MIB views each of which contains some subset of the information. So, by providing access rights to a group in terms of the particular (subset) MIB view it can access for that context, then the group is restricted in the desired manner. Since managed object types (and their instances) are identified via the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO-ASN.1, RFC1902], it is convenient to define a MIB view as the combination of a set of "view subtrees", where each view subtree is a subtree within the managed object naming tree. Thus, a simple MIB view (e.g., all managed objects within the Internet Network Management Framework) can be defined as a single view subtree, while more complicated MIB views (e.g., all information relevant to a particular network interface) can be represented by the union of multiple view subtrees. While any set of managed objects can be described by the union of some number of view subtrees, situations can arise that would require a very large number of view subtrees. This could happen, for example, when specifying all columns in one conceptual row of a MIB table because they would appear in separate subtrees, one per column, each with a very similar format. Because the formats are similar, the required set of subtrees can easily be aggregated into one structure. This structure is named a family of view subtrees after the set of subtrees that it conceptually represents. A family of view subtrees can either be included or excluded from a MIB view. 2.4.1. View Subtree A view subtree is the set of all MIB object instances which have a common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is identified by the OBJECT IDENTIFIER value which is the longest OBJECT IDENTIFIER prefix common to all (potential) MIB object instances in that subtree. 2.4.2. ViewTreeFamily A family of view subtrees is a pairing of an OBJECT IDENTIFIER value (called the family name) together with a bit string value (called Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 7] Draft View-based Access Control Model (ACM) for SNMP July 1997 the family mask). The family mask indicates which sub-identifiers of the associated family name are significant to the family's definition. For each possible managed object instance, that instance belongs to a particular ViewTreeFamily if both of the following conditions are true: - the OBJECT IDENTIFIER name of the managed object instance contains at least as many sub-identifiers as does the family name, and - each sub-identifier in the OBJECT IDENTIFIER name of the managed object instance matches the corresponding sub-identifier of the family name whenever the corresponding bit of the associated family mask is non-zero. When the configured value of the family mask is all ones, the view subtree family is identical to the single view subtree identified by the family name. When the configured value of the family mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family having a family mask of zero length always corresponds to a single view subtree. 2.5. Access Policy The View-based Access Control Model determines the access rights of a group (representing zero, one or more securityNames which have the same access rights). For a particular context (contextName) to which a group (groupName) has access using a particular Security Model (securityModel) and Level of Security (LoS), that group's access rights are given by a read-view, a write-view and a notify-view. The read-view represents the set of object instances authorized for the group when reading objects. Reading objects occurs when processing a retrieval (for example a GetRequest, GetNextRequest, GetBulkRequest) operation. The write-view represents the set of object instances authorized for the group when writing objects. Writing objects occurs when processing a write (for example a Set) operation. The notify-view represents the set of object instances authorized for the group when sending objects in a notification. This occurs when sending a notification (for example an Inform or SNMPv2-Trap). Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 8] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 3. Elements of Procedure This section describes the procedures followed by an Access Control module, that implements the View-based Access Control Model, when checking access rights as requested by an application (for example a Command Responder or a Notification Originator application). The abstract service interface primitive is: statusInformation = -- success or errorIndication isAccessAllowed( securityModel -- Security Model in use securityName -- principal who wants to access LoS -- Level of Security viewType -- read, write, or notify view contextName -- context containing variableName variableName -- OID for the managed object ) Where: statusInformation one of the following: accessAllowed - success (and access is granted). a MIB view was found and access is granted. notInView - success (but access is denied). a MIB view was found but access is denied because the variableName is not in the configured MIB view for the specified viewType (e.g. in the relevant entry in the acmAccessTable). noSuchView - failure, no MIB view found because no view configured for specified viewType (e.g. in the relevant entry in the acmAccessTable). noSuchContext - failure, no MIB view found because no entry in the acmContextTable for the specified contextName. noGroupName - failure, no MIB view found because no entry configured in the acmSecurityToGroupTable for the specified combination of securityModel and securityName. noAccessEntry - failure, no MIB view found because no entry configured in the acmAccessTable for the specified combination of contextName, groupName (as found in the acmSecurityToGroupTable based on securityModel and securityName), securityModel and LoS. otherError - failure, an undefined error occurred. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 9] Draft View-based Access Control Model (ACM) for SNMP July 1997 securityModel Security Model under which access is requested. securityName representing the principal on whose behalf access is requested. LoS Level of Security under which access is requested. viewType view to be checked (read, write or notify). contextName context in which access to variableName is requested. variableName variable (object instance) to which access is requested. 3.1 Processing the isAccessAllowed Service Request This section describes the procedure followed by an Access Control module, that implements the View-based Access Control Model, whenever it receives an isAccessAllowed request. 1) The LCD (acmContextTable) is consulted for information about the SNMP context identified by the contextName. If information about this SNMP context is absent from the LCD, then an errorIndication (noSuchContext) is returned to the calling module. 2) The LCD (acmSecurityToGroupTable) is consulted for mapping the Security Model (securityModel) and principal (securityName) to a group (groupName). If that information about this combination is absent from the LCD, then an errorIndication (noGroupName) is returned to the calling module. 3) The LCD (acmAccessTable) is consulted for information about the contextName, groupName, securityModel and LoS. If information about this combination is absent from the LCD, then an errorIndication (noAccessEntry) is returned to the calling module. 4) a) If the viewType is "read", then the read view is used for checking access rights. b) If the viewType is "write", then the write view is used for checking access rights. c) If the viewType is "notify", then the notify view is used for checking access rights. 5) a) If there is no view configured for the specified viewType, then an errorIndication (noSuchView) is returned to the calling module. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 10] Draft View-based Access Control Model (ACM) for SNMP July 1997 b) If the specified variableName (object instance) is not in the MIB view (see DESCRIPTION clause for acmViewTreeFamilyTable in section 4), then an errorIndication (notInView) is returned to the calling module. Otherwise, c) The specified variableName is in the MIB view. A statusInformation of success (accessAllowed) is returned to the calling module. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 11] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 4. Definitions SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI TestAndIncr, RowStatus, StorageType FROM SNMPv2-TC SnmpAdminString, SnmpLoS, SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; snmpAcmMIB MODULE-IDENTITY LAST-UPDATED "9707140000Z" -- 14 July 1997, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@tis.com Subscribe: majordomo@tis.com In message body: subscribe snmpv3 Chair: Russ Mundy Trusted Information Systems postal: 3060 Washington Rd Glenwood MD 21738 USA email: mundy@tis.com phone: +1-301-854-6889 Co-editor: Bert Wijnen IBM T.J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-432-794 Co-editor: Randy Presuhn BMC Software, Inc postal: 1190 Saratoga Avenue, Suite 130 San Jose, CA 95129-3433 USA email: rpresuhn@bmc.com phone: +1-408-556-0720 Co-editor: Keith McCloghrie Cisco Systems, Inc. postal: 170 West Tasman Drive San Jose, CA 95134-1706 USA email: kzm@cisco.com Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 12] Draft View-based Access Control Model (ACM) for SNMP July 1997 phone: +1-408-526-5260 " DESCRIPTION "The management information definitions for the View-based Access Control Model for SNMP. " ::= { snmpModules 10 } -- to be verified with IANA -- Administrative assignments **************************************** acmMIBObjects OBJECT IDENTIFIER ::= { snmpAcmMIB 1 } acmMIBConformance OBJECT IDENTIFIER ::= { snmpAcmMIB 2 } -- Information about Local Contexts ********************************** acmContextTable OBJECT-TYPE SYNTAX SEQUENCE OF AcmContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of locally available contexts. If a context is listed in this table that does not mean that access to this context has been defined in the acmAccessTable. It just means that the context exists and that MIB objects may exist in this context. This table must be made accessible via the default context. This table is read-only meaning that it cannot be configured via SNMP. This table is provides information to SNMP Command Generator applications so they can properly configure the acmAccessTable to control access to all contexts at the SNMP entity that provides access to the information in these contexts. " ::= { acmMIBObjects 1 } acmContextEntry OBJECT-TYPE SYNTAX AcmContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular context." INDEX { acmContextName } ::= { acmContextTable 1 } AcmContextEntry ::= SEQUENCE { Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 13] Draft View-based Access Control Model (ACM) for SNMP July 1997 acmContextName SnmpAdminString } acmContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "A human readable name identifying a particular context at a particular SNMP entity. " ::= { acmContextEntry 1 } -- Information about Groups ****************************************** acmSecurityToGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF AcmSecurityToGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table that maps a combination of securityModel and securityName into a groupName which defines an access control policy for a group of principals. " ::= { acmMIBObjects 2 } acmSecurityToGroupEntry OBJECT-TYPE SYNTAX AcmSecurityToGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table maps the combination of a securityModel and securityName into a groupName. " INDEX { acmSecurityModel, acmSecurityName } ::= { acmSecurityToGroupTable 1 } AcmSecurityToGroupEntry ::= SEQUENCE { acmSecurityModel SnmpSecurityModel, acmSecurityName SnmpAdminString, acmGroupName SnmpAdminString, acmSecurityToGroupStorageType StorageType, acmSecurityToGroupStatus RowStatus } acmSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Security Model, which is the first index in this Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 14] Draft View-based Access Control Model (ACM) for SNMP July 1997 table. " ::= { acmSecurityToGroupEntry 1 } acmSecurityName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The securityName for a principal represented in a Security Model independent format. Used as a second index in this table. " ::= { acmSecurityToGroupEntry 2 } acmGroupName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the group to which this entry (e.g. the combination of securityModel and securityName) belongs. This groupName represents an access control policy and is used as an index in the acmAccessTable. " ::= { acmSecurityToGroupEntry 3 } acmSecurityToGroupStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { acmSecurityToGroupEntry 4 } acmSecurityToGroupStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The value of this object has no effect on whether other objects in this conceptual row can be modified. " ::= { acmSecurityToGroupEntry 5 } -- Reverse mapping from groupName into securityName(s) *************** Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 15] Draft View-based Access Control Model (ACM) for SNMP July 1997 acmGroupListTable OBJECT-TYPE SYNTAX SEQUENCE OF AcmGroupListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The acmGroupListTable complements the acmSecurityToGroupTable by providing an efficient means to determine the membership of a given group. " ::= { acmMIBObjects 3 } acmGroupListEntry OBJECT-TYPE SYNTAX AcmGroupListEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table corresponds to an entry in the acmSecurityToGroupTable, using acmGroupName as its primary key. " INDEX { acmGroupName, acmSecurityModel, acmSecurityName } ::= { acmGroupListTable 1 } AcmGroupListEntry ::= SEQUENCE { acmGroupListStatus RowStatus } acmGroupListStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of this conceptual row. The value is identical to that of the corresponding acmSecurityToGroupEntry's acmSecurityToGroupStatus. " ::= { acmGroupListEntry 1 } -- Information about Access Rights *********************************** acmAccessTable OBJECT-TYPE SYNTAX SEQUENCE OF AcmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of group access rights configured in the Local Configuration Datastore (LCD). Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 16] Draft View-based Access Control Model (ACM) for SNMP July 1997 Each entry is indexed by a contextPrefix, a groupName a securityModel and a Level of Security (LoS). To determine whether access is allowed, one entry from this table needs to be selected and the proper viewName from that entry must be used for access control checking. To select the proper entry, first a match must be found for the contextPrefix. The procedure for this process depends on the value of acmAccessContextMatch: - exact In this case, the acmAccessContextPrefix represents an exact contextName, and so the name must match exactly. - prefix In this case, the acmAccessContextPrefix represents a prefix of a contextName, so that (a limited form of) wildcarding is possible. The value of acmAccessContextPrefix must match with the first part of the contextName to which access is requested. For example, if an acmAccessContextPrefix value of 'repeater' is used, then both contexts named 'repeater1' and 'repeater2' are accessible. Multiple entries could match. In that case: - The entry which has the longest value for acmAccessContextPrefix wins. Otherwise, if still no single winner (e.g. multiple entries have the same acmAccessContextPrefix value, - The entry which has the value 'exact' for the corresponding acmAccessContextMatch, wins. Otherwise, if still no single winner (e.g. multiple entries have a acmAccessContextMatch value 'exact', - Then continue. At the 4th match to make a final winner will be found if there are still multiple entries. The second match to make is for the groupName. Here an exact match must be found. The 3rd match to make is for the securityModel. Here an exact match must be found. If no such exact Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 17] Draft View-based Access Control Model (ACM) for SNMP July 1997 match exists, then an entry that has the 'all' value (see definition of SnmpSecurityModel in [SNMP-ARCH]) for the acmAccessSecurityModel is considered to match. The 4th match to make is for the LoS. Here the LoS at which access is requested must be greater than or equal to the value of the acmAccessLoS. If multiple entries are still considered to match, then the entry which has the lowest value for the corresponding acmAccessLoS wins. " ::= { acmMIBObjects 4 } acmAccessEntry OBJECT-TYPE SYNTAX AcmAccessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An access right configured in the Local Configuration Datastore (LCD) authorizing access to an SNMP context. " INDEX { acmAccessContextPrefix, acmGroupName, acmSecurityModel, acmAccessLoS } ::= { acmAccessTable 1 } AcmAccessEntry ::= SEQUENCE { acmAccessContextPrefix SnmpAdminString, acmAccessLoS SnmpLoS, acmAccessContextMatch INTEGER, acmAccessReadViewName SnmpAdminString, acmAccessWriteViewName SnmpAdminString, acmAccessNotifyViewName SnmpAdminString, acmAccessStorageType StorageType, acmAccessStatus RowStatus } acmAccessContextPrefix OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "In order to gain the access rights allowed by this conceptual row, a contextName must match exactly (if the value of acmAccessContextMatch is 'exact') or partially (if the value of acmAccessContextMatch is 'prefix') to the value of the instance of this object. " ::= { acmAccessEntry 1 } Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 18] Draft View-based Access Control Model (ACM) for SNMP July 1997 acmAccessLoS OBJECT-TYPE SYNTAX SnmpLoS MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum level of security required in order to gain the access rights allowed by this conceptual row. An LoS of noAuthNoPriv is lower than authNoPriv which in turn is lower than authPriv. If multiple entries are equally indexed except for this acmAccessLoS index, then the entry which has the lowest value for acmAccessLoS wins. " ::= { acmAccessEntry 2 } acmAccessContextMatch OBJECT-TYPE SYNTAX INTEGER { exact (1), -- exact match of prefix and contextName prefix (2) -- Only match to the prefix } MAX-ACCESS read-create STATUS current DESCRIPTION "If exact is set, then the value of the index part acmAccessContextPrefix of this entry in this table represents a full contextName. If prefix is set, then the value of the index part acmAccessContextPrefix of this entry in this table represents a partial contextName which acts as a prefix so that a simple form of wildcarding is possible. " ::= { acmAccessEntry 3 } acmAccessReadViewName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes read access. The identified MIB view is that one for which the acmViewTreeFamilyViewName has the same value as the instance of this object; if the value is the empty string or if there is no active MIB view having this value of acmViewTreeFamilyViewName, then no access is granted. " DEFVAL { ''H } -- the empty string Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 19] Draft View-based Access Control Model (ACM) for SNMP July 1997 ::= { acmAccessEntry 4 } acmAccessWriteViewName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes write access. The identified MIB view is that one for which the acmViewTreeFamilyViewName has the same value as the instance of this object; if the value is the empty string or if there is no active MIB view having this value of acmViewTreeFamilyViewName, then no access is granted. " DEFVAL { ''H } -- the empty string ::= { acmAccessEntry 5 } acmAccessNotifyViewName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes access for notifications. The identified MIB view is that one for which the acmViewTreeFamilyViewName has the same value as the instance of this object; if the value is the empty string or if there is no active MIB view having this value of acmViewTreeFamilyViewName, then no access is granted. " DEFVAL { ''H } -- the empty string ::= { acmAccessEntry 6 } acmAccessStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { acmAccessEntry 7 } acmAccessStatus OBJECT-TYPE Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 20] Draft View-based Access Control Model (ACM) for SNMP July 1997 SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The value of this object has no effect on whether other objects in this conceptual row can be modified. " ::= { acmAccessEntry 8 } -- Information about MIB views *************************************** -- Support for views having instance-level granularity is optional acmMIBViews OBJECT IDENTIFIER ::= { acmMIBObjects 5 } acmViewSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow cooperating SNMP Command Generator applications to coordinate their use of the Set operation in creating view subtrees. When creating a new view or altering an existing view, it is important to understand the potential interactions with other uses of the view. The acmViewSpinLock should be retrieved. The name of the view to be created should be determined to be unique by the SNMP Command Generator application by consulting the acmViewTreeFamilyTable. Finally, the named view may be created (Set), including the advisory lock. If another SNMP Command Generator application has altered the views in the meantime, then the spin lock's value will have changed, and so this creation will fail because it will specify the wrong value for the spin lock. Since this is an advisory lock, the use of this lock is not enforced. " ::= { acmMIBViews 1 } acmViewTreeFamilyTable OBJECT-TYPE SYNTAX SEQUENCE OF AcmViewTreeFamilyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about families of subtrees within MIB views. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 21] Draft View-based Access Control Model (ACM) for SNMP July 1997 Each MIB view is defined by two sets of view subtrees: - the included view subtrees, and - the excluded view subtrees. Every such view subtree, both included and excluded, is defined in this table. To determine if a particular object instance is in a particular MIB view, compare the object instance's OBJECT IDENTIFIER with each of the MIB view's active entries in this table. If none match, then the object instance is not in the MIB view. If one or more match, then the object instance is included in, or excluded from, the MIB view according to the value of acmViewTreeFamilyType in the entry whose value of acmViewTreeFamilySubtree has the most sub-identifiers. If multiple entries match and have the same number of sub-identifiers, then the lexicographically greatest instance of acmViewTreeFamilyType determines the inclusion or exclusion. An object instance's OBJECT IDENTIFIER X matches an active entry in this table when the number of sub-identifiers in X is at least as many as in the value of acmViewTreeFamilySubtree for the entry, and each sub-identifier in the value of acmViewTreeFamilySubtree matches its corresponding sub-identifier in X. Two sub-identifiers match either if the corresponding bit of the value of acmViewTreeFamilyMask for the entry is zero (the 'wild card' value), or if they are equal. A 'family' of subtrees is the set of subtrees defined by a particular combination of values of acmViewTreeFamilySubtree and acmViewTreeFamilyMask. In the case where no 'wild card' is defined in the acmViewTreeFamilyMask, the family of subtrees reduces to a single subtree. When an SNMP Command Generator application wants to create a new MIB view, then it should first obtain the value of the advisory spin lock and a list of existing named views. It then selects a new non-existing index-value (viewName) for acmViewTreeFamilyViewName. The SNMP Command Generator application can then start creating entries in the acmViewTreeFamilyTable. It should include the advisory lock in the Set Operation to ensure that an other such application has not in the meanwhile created new entries with a new (possibly colliding) viewName in this table. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 22] Draft View-based Access Control Model (ACM) for SNMP July 1997 When creating MIB views, it is strongly advised that first the 'excluded' acmViewTreeFamilyEntries are created and then the 'included' entries. When deleting MIB views, it is strongly advised that first the 'included' acmViewTreeFamilyEntries are deleted and then the 'excluded' entries. " ::= { acmMIBViews 2 } acmViewTreeFamilyEntry OBJECT-TYPE SYNTAX AcmViewTreeFamilyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular family of view subtrees included in or excluded from a particular SNMP context's MIB view. Implementations must not restrict the number of families of view subtrees for a given MIB view, except as dictated by resource constraints on the overall number of entries in the acmViewTreeFamilyTable. The value of acmViewTreeFamilyViewName in the INDEX clause of this table identifies the MIB view in which this subtree family exists. A MIB view (viewName) for which there are no conceptual rows in this table is the empty set of view subtrees. " INDEX { acmViewTreeFamilyViewName, acmViewTreeFamilySubtree } ::= { acmViewTreeFamilyTable 1 } AcmViewTreeFamilyEntry ::= SEQUENCE { acmViewTreeFamilyViewName SnmpAdminString, acmViewTreeFamilySubtree OBJECT IDENTIFIER, acmViewTreeFamilyMask OCTET STRING, acmViewTreeFamilyType INTEGER, acmViewTreeFamilyStorageType StorageType, acmViewTreeFamilyStatus RowStatus } acmViewTreeFamilyViewName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 23] Draft View-based Access Control Model (ACM) for SNMP July 1997 STATUS current DESCRIPTION "The human readable name for a family of view subtrees. " ::= { acmViewTreeFamilyEntry 1 } acmViewTreeFamilySubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MIB subtree which when combined with the corresponding instance of acmViewTreeFamilyMask defines a family of view subtrees. " ::= { acmViewTreeFamilyEntry 2 } acmViewTreeFamilyMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The bit mask which, in combination with the corresponding instance of acmViewTreeFamilySubtree, defines a family of view subtrees. Each bit of this bit mask corresponds to a sub-identifier of acmViewTreeFamilySubtree, with the most significant bit of the i-th octet of this octet string value (extended if necessary, see below) corresponding to the (8*i - 7)-th sub-identifier, and the least significant bit of the i-th octet of this octet string corresponding to the (8*i)-th sub-identifier, where i is in the range 1 through 16. Each bit of this bit mask specifies whether or not the corresponding sub-identifiers must match when determining if an OBJECT IDENTIFIER is in this family of view subtrees; a '1' indicates that an exact match must occur; a '0' indicates 'wild card', i.e., any sub-identifier value matches. Thus, the OBJECT IDENTIFIER X of an object instance is contained in a family of view subtrees if, for each sub-identifier of the value of acmViewTreeFamilySubtree, either: the i-th bit of acmViewTreeFamilyMask is 0, or the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of acmViewTreeFamilySubtree. If the value of this bit mask is M bits long and Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 24] Draft View-based Access Control Model (ACM) for SNMP July 1997 there are more than M sub-identifiers in the corresponding instance of acmViewTreeFamilySubtree, then the bit mask is extended with 1's to be the required length. Note that when the value of this object is the zero-length string, this extension rule results in a mask of all-1's being used (i.e., no 'wild card'), and the family of view subtrees is the one view subtree uniquely identified by the corresponding instance of acmViewTreeFamilySubtree. " DEFVAL { ''H } ::= { acmViewTreeFamilyEntry 3 } acmViewTreeFamilyType OBJECT-TYPE SYNTAX INTEGER { included(1), excluded(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The indication of whether the corresponding instances of acmViewTreeFamilySubtree and acmViewTreeFamilyMask define a family of view subtrees which is included in or excluded from the MIB view. " DEFVAL { included } ::= { acmViewTreeFamilyEntry 4 } acmViewTreeFamilyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { acmViewTreeFamilyEntry 5 } acmViewTreeFamilyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. The value of this object has no effect on whether other objects in this conceptual row can be modified. " ::= { acmViewTreeFamilyEntry 6 } -- Conformance information ******************************************* Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 25] Draft View-based Access Control Model (ACM) for SNMP July 1997 acmMIBCompliances OBJECT IDENTIFIER ::= { acmMIBConformance 1 } acmMIBGroups OBJECT IDENTIFIER ::= { acmMIBConformance 2 } -- Compliance statements ********************************************* acmMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP View-based Access Control Model configuration MIB. " MODULE -- this module MANDATORY-GROUPS { acmBasicGroup } OBJECT acmAccessContextMatch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acmAccessReadViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acmAccessWriteViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acmAccessNotifyViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acmAccessStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acmAccessStatus MIN-ACCESS read-only DESCRIPTION "Create access to the acmAccessTable is not required. " OBJECT acmViewTreeFamilyMask WRITE-SYNTAX OCTET STRING (SIZE (0)) MIN-ACCESS read-only DESCRIPTION "Support for configuration via SNMP of subtree families using wild-cards is not required. " OBJECT acmViewTreeFamilyType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 26] Draft View-based Access Control Model (ACM) for SNMP July 1997 OBJECT acmViewTreeFamilyStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT acmViewTreeFamilyStatus MIN-ACCESS read-only DESCRIPTION "Create access to the acmViewTreeFamilyTable is not required. " ::= { acmMIBCompliances 1 } -- Units of conformance ********************************************** acmBasicGroup OBJECT-GROUP OBJECTS { acmContextName, acmGroupName, acmSecurityToGroupStorageType, acmSecurityToGroupStatus, acmGroupListStatus, acmAccessContextMatch, acmAccessReadViewName, acmAccessWriteViewName, acmAccessNotifyViewName, acmAccessStorageType, acmAccessStatus, acmViewSpinLock, acmViewTreeFamilyMask, acmViewTreeFamilyType, acmViewTreeFamilyStorageType, acmViewTreeFamilyStatus } STATUS current DESCRIPTION "A collection of objects providing for remote configuration of an SNMP engine which implements the SNMP View-based Access Control Model (ACM). " ::= { acmMIBGroups 1 } END Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 27] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 5. Security Considerations 5.1. Recommended Practices This document is meant for use in the SNMP architecture. The View-based Access Control Model (ACM) described in this document checks access rights to management information based on: - contextName, representing a set of management information at the managed system where the Access Control module is running. - groupName, representing a group or set of zero, one or more securityNames. The combination of a securityModel and a securityName is mapped into a group in the View-based Access Control Model. - securityModel used for the transmission of an SNMP message. - Level of Security (LoS) used for the transmission of an SNMP message. - operation performed on the management information. - MIB views for read, write or notify access. When the User-based Access Control module (ACM) is called for checking access rights, it is assumed that the calling module has ensured the authentication and privacy aspects as specified by the Level of Security (LoS) that is being passed. 5.2. Defining Groups The groupNames are used to give access to a group of zero, one or more securityNames. Within the ACM, a groupName is considered to exist if that groupName is listed in the acmSecurityToGroupTable. By mapping the combination of a securityModel and securityName into a groupName, an SNMP Command Generator application can add/delete securityNames to/from a group, that is if proper access is allowed. 5.3. Conformance For an implementation of the View-based Access Control Model to be conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also SHOULD [RFC2119] implement the initial configuration, described in appendix A. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 28] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 6. Editor's Addresses Co-editor: Bert Wijnen IBM T. J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-432-794 Co-editor: Randy Presuhn BMC Software, Inc postal: 1190 Saratoga Avenue, Suite 130 San Jose, CA 95129-3433 USA email: rpresuhn@bmc.com phone: +1-408-556-0720 Co-editor: Keith McCloghrie Cisco Systems, Inc. postal: 170 West Tasman Drive San Jose, CA 95134-1706 USA email: kzm@cisco.com phone: +1-408-526-5260 7. Acknowledgements This document describes the work of the SNMP Security and Administrative Framework Evolution team, comprised of David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research) Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 29] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 8. References [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [RFC2119] Network Working Group, Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An Architecture for describing Internet Management Frameworks", draft-ietf-snmpv3-next-gen-arch-02.txt, June 1997. [SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D., "Message Processing and Control Model for version 3 of the Simple Network Management Protocol (SNMPv3)", draft-ietf-snmpv3-mpc-00.txt, July 1997. [SNMPv3-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", draft-ietf-snmpv3-usm-00.txt, July 1997. [ISO-ASN.1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 30] ^L Draft View-based Access Control Model (ACM) for SNMP July 1997 APPENDIX A - Installation A.1. Installation Parameters During installation, an authoritative SNMP engine SHOULD (in the meaning as defined in [RFC2119]) be configured with several initial parameters. These include for the View-based Access Control Model: 1) A security posture The choice of security posture determines if initial configuration is implemented and if so how. One of three possible choices is selected: minimum-secure, semi-secure, very-secure (i.e. no-initial-configuration) In the case of a very-secure posture, there is no initial configuration, and so the following steps are irrelevant. 2) A default context One entry in the acmContextTable with a contextName of "" (the empty string), representing the default context. Note that this table gets created automatically if a default context exists. no privacy support privacy support ------------------ --------------- acmContextName "" "" 3) An initial group One entry in the acmSecurityToGroupTable to allow access to group "initial". no privacy support privacy support ------------------ --------------- acmSecurityModel 3 (USM) 3 (USM) acmSecurityName "initial" "initial" acmGroupName "initial" "initial" acmSecurityToGroupStorageType anyValidStorageType anyValidStorageType acmSecurityToGroupStatus active active 4) An initial acmGroupListTable Those columns marked with (index) are index-only objects and are not really present in this table. Note that this table gets created automatically because of the configuration of the initial group. One entry in the acmGroupListTable as follows: Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 31] Draft View-based Access Control Model (ACM) for SNMP July 1997 no privacy support privacy support ------------------ --------------- acmGroupName (index) "initial" "initial" acmSecurityModel (index) 3 (USM) 3 (USM) acmSecurityName (index) "initial" "initial" acmGroupListStatus active active 5) Initial access rights Three entries in the acmAccessTable as follows: - read-notify access for securityModel USM, LoS "noAuthNoPriv" on behalf of securityNames that belong to the group "initial" to the MIB view in the context with contextName "". - read-write-notify access for securityModel USM, LoS "authNoPriv" on behalf of securityNames that belong to the group "initial" to the MIB view in the context with contextName "". - if privacy is supported, read-write-notify access for securityModel USM for LoS "authPriv" on behalf of securityNames that belong to the group "initial" to the MIB view in the context with contextName "". That translates into the following entries in the acmAccessTable. Those columns marked with (index) are index-only objects and are not really present in this table at all. - One entry to be used for unauthenticated access (noAuthNoPriv): no privacy support privacy support ------------------ --------------- acmAccessContextPrefix "" "" acmGroupName (index) "initial" "initial" acmSecurityModel (index) 3 (USM) 3 (USM) acmAccessLoS noAuthNoPriv noAuthNoPriv acmAccessReadViewName "restricted" "restricted" acmAccessWriteViewName "" "" acmAccessNotifyViewName "restricted" "restricted" acmAccessStorageType anyValidStorageType anyValidStorageType acmAccessStatus active active - One entry to be used for authenticated access but without privacy (authNoPriv): no privacy support privacy support ------------------ --------------- acmAccessContextPrefix "" "" acmGroupName (index) "initial" "initial" acmSecurityModel (index) 3 (USM) 3 (USM) Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 32] Draft View-based Access Control Model (ACM) for SNMP July 1997 acmAccessLoS authNoPriv authNoPriv acmAccessReadViewName "all-iso" "all-iso" acmAccessWriteViewName "all-iso" "all-iso" acmAccessNotifyViewName "all-iso" "all-iso" acmAccessStorageType anyValidStorageType anyValidStorageType acmAccessStatus active active - One entry to be used for authenticated access with privacy (authPriv): no privacy support privacy support ------------------ --------------- acmAccessContextPrefix "" acmGroupName (index) "initial" acmSecurityModel (index) 3 (USM) acmAccessLoS authPriv acmAccessReadViewName "all-iso" acmAccessWriteViewName "all-iso" acmAccessNotifyViewName "all-iso" acmAccessStorageType anyValidStorageType acmAccessStatus active Note however, that this last entry is also covered by the entry that allows authNoPriv access because the authPriv access is a better LoS than the authNoPriv. 6) Two MIB views depending on the security posture. - One view (the view) for authenticated access: - the MIB view is the following subtree: "iso" (subtree 1) - A second view (the view) for unauthenticated access. This view is configured according to the selected security posture: - For the "very-secure" posture there is no default initial configuration, so no MIB views are pre-scribed. - For the "semi-secure" posture: the MIB view is the union of these subtrees: (a) "system" (subtree 1.3.6.1.2.1.1) [RFC1907] (b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC1907] (c) "snmpEngine" (subtree 1.3.6.1.6.3.7.2.1) [SNMP-ARCH] (d) "snmpV3Stats" (subtree 1.3.6.1.6.3.8.2.1) [SNMPv3-MPC] (e) "usmStats" (subtree 1.3.6.1.6.3.9.2.1) [SNMPv3-USM] - For the "minimum-secure" posture: Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 33] Draft View-based Access Control Model (ACM) for SNMP July 1997 the MIB view is the following subtree. "iso" (subtree 1) This translates into the following "all-iso" entry in the acmViewTreeFamilyTable: minimum-secure semi-secure ---------------- --------------- acmViewTreeFamilyViewName "all-iso" "all-iso" acmViewTreeFamilySubtree 1 1 acmViewTreeFamilyMask "" "" acmViewTreeFamilyType 1 (included) 1 (included) acmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType acmViewTreeFamilyStatus active active This translates into the following "restricted" entries in the acmViewTreeFamilyTable: minimum-secure semi-secure ---------------- --------------- acmViewTreeFamilyViewName "restricted" "restricted" acmViewTreeFamilySubtree 1 1.3.6.1.2.1.1 acmViewTreeFamilyMask " " "" acmViewTreeFamilyType 1 (included) 1 (included) acmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType acmViewTreeFamilyStatus active active acmViewTreeFamilyViewName "restricted" acmViewTreeFamilySubtree 1.3.6.1.2.1.11 acmViewTreeFamilyMask "" acmViewTreeFamilyType 1 (included) acmViewTreeFamilyStorageType anyValidStorageType acmViewTreeFamilyStatus active acmViewTreeFamilyViewName "restricted" acmViewTreeFamilySubtree 1.3.6.1.6.3.7.2.1 acmViewTreeFamilyMask "" acmViewTreeFamilyType 1 (included) acmViewTreeFamilyStorageType anyValidStorageType acmViewTreeFamilyStatus active acmViewTreeFamilyViewName "restricted" acmViewTreeFamilySubtree 1.3.6.1.6.3.8.2.1 acmViewTreeFamilyMask "" acmViewTreeFamilyType 1 (included) acmViewTreeFamilyStorageType anyValidStorageType acmViewTreeFamilyStatus active acmViewTreeFamilyViewName "restricted" acmViewTreeFamilySubtree 1.3.6.1.6.3.9.2.1 acmViewTreeFamilyMask "" Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 34] Draft View-based Access Control Model (ACM) for SNMP July 1997 acmViewTreeFamilyType 1 (included) acmViewTreeFamilyStorageType anyValidStorageType acmViewTreeFamilyStatus active Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 35] Draft View-based Access Control Model (ACM) for SNMP July 1997 Table of Contents 0. Issues and Change Log 2 0.1. Issues 2 0.2. Change Log 2 1. Introduction 4 1.2. Access Control 4 1.3. Local Configuration Datastore 5 2. Elements of the Model 6 2.1. groupName 6 2.2. Level of Security (LoS) 6 2.3. Contexts 6 2.4. MIB Views and View Families 7 2.4.1. View Subtree 7 2.4.2. ViewTreeFamily 7 2.5. Access Policy 8 3. Elements of Procedure 9 3.1 Processing the isAccessAllowed Service Request 10 4. Definitions 12 5. Security Considerations 28 5.1. Recommended Practices 28 5.2. Defining Groups 28 5.3. Conformance 28 6. Editor's Addresses 29 7. Acknowledgements 29 8. References 30 A.1. Installation Parameters 31 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 36]