Internet Draft Access Control Model for version 3 of the Simple Network Management Protocol (SNMPv3) 18 June 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 <draft-ietf-snmpv3-acm-00.txt> 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 Access Control Model (ACM) for SNMP version 3 for use in the SNMP architecture [SNMP-ARCH]. This document defines the Elements of Procedure for applying access control to management information. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this ACM. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 1] Draft Access Control Model (ACM) for SNMPv3 June 1997 0.1 Issues - Where do we do the miId to groupName mapping - Should we use UTF-8 for human readable names like contextName, viewName, groupName etc. We now use a SnmpAdminString TC which still needs to be defined. - acknowledgements needs expansion - Do we want to mandate a standard out-of-the-box configuration. - How do we return a proper indication of the error-counter to be used in a possible reportPDU. - Do we keep the statistics (error counters) here or in MPC 0.2 Change Log [version 3.1] - This is the June 18 version. - remove old (resolved) issues - 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 secModel - add groupTable - add/rename Stats counters Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 2] Draft Access Control Model (ACM) for SNMPv3 June 1997 1. Introduction The Architecture for describing Internet Management Frameworks is composed of multiple subsystems: 1) a message processing and control subsystem, 2) a security subsystem, 3) an access control subsystem, and 4) orangelets. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the 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 of the SNMP architecture, as defined in [SNMP-ARCH]. The Access Control subsystem of an SNMP engine provides services to orangelets so that these orangelets can check if access to an object is allowed or not. 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 SNMP version 3 Access Control model. 1.2 Access Control Access Control occurs (either implicit or explicit) in an SNMP engine acting in an agent role when processing SNMP request messages from an SNMP engine acting in a manager role. These request messages include these types of operations: GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations. Access Control also occurs in an SNMP engine when an SNMP notification message is generated. These notification messages include these types of operations: InformRequest and SNMPv2-trap operations. Access Control via the Access Control module only occurs if the orangelet that processes or generates the operation explicitly calls upon the access control service for checking of access rights. So it is the responsibility of an orangelet to make the proper calls for access checking. 1.3 Local Configuration Datastore To implement the model described in this document, each SNMP engine needs to retain its own set of information about access Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 3] Draft Access Control Model (ACM) for SNMPv3 June 1997 rights and policies, and the like. This set of information is called the SNMP engine's Local Configuration Datastore (LCD) because it is locally-stored information. In order to allow an SNMP engine's LCD to be remotely configured, portions of the LCD need to be accessible as managed objects. A MIB module, the SNMPv3 Access Control Model Configuration MIB, which defines these managed object types is included in this document. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 4] Draft Access Control Model (ACM) for SNMPv3 June 1997 2. Elements of the Model This section contains definitions to realize the access control applied by this Access Control Model. 2.1 Groups A groupName identifies a group (set) of zero or more securityIdentities on whose behalf SNMP management objects can be accessed. The Access Control module assumes the securityIdentity has already been authenticated as needed and provides no authentication by itself. This SNMPv3 Access Control model requires the securityModel and the securityIdentity to be passed as input to the Access Control module when a request is made to check for access rights. 2.2 Level of Security (LoS) Different access rights can be defined for different Levels of Security. The LoS identifies the Level of Security that will be assumed when checking for access rights. This Access Control Model requires the LoS to be passed as input to the Access Control module when a request is made to check access rights. 2.3 Contexts An SNMP context is a collection of management information accessible by an SNMP agent. An item of management information may exist in more than one context. An SNMP agent potentially has access to many contexts. 2.4 Access Policy This Access Control model determines the access rights of groups (representing zero, one or more securityIdentities which have the same access rights). For a particular context (contextName) to which a group (groupName) has access using a particular 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 is the set of object instances authorized for the group when reading objects. Reading objects occurs when processing a retrieval (Get, GetNext, GetBulk) operation. The write-view is the set of object instances authorized for the group when writing objects. Writing objects occurs when processing a Set operation. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 5] Draft Access Control Model (ACM) for SNMPv3 June 1997 The notify-view is the set of object instances authorized for the group when sending objects in a notification. Such occurs when sending a notification (Inform or Trap). Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 6] Draft Access Control Model (ACM) for SNMPv3 June 1997 3. Elements of Procedure This section describes the procedures followed by the Access Control module that implements this Access Control Model when checking access rights as requested by an orangelet. The abstract service interface into the access control service is: Boolean is_access_allowed ( secModel, miId, LoS, viewType, contextName, variableName ) Where: Boolean - FALSE if no access is allowed. TRUE if access is allowed. secModel - security model to which the miId belongs. miId - security model independent ID (securityIdentity). LoS - Level of Security viewType - view to be checked (read, write or notify). contextName - context in which the variable_name is accessed. variableName - variable that is accessed. 3.1 Processing the is_access_allowed service request This section describes the procedure followed by the Access Control module whenever it receives a request to check if access is allowed. (1) The LCD (snmpV3AcContextTable) is consulted for information about the SNMP context identified by the contextName. If information about this SNMP context is absent from the LCD, then the snmpV3AcStatsUnknownContexts counter is incremented, and FALSE is returned to the caller. (2) The LCD (snmpV3AcGroupTable) is consulted for information about the security model (secModel) and securityIdentity (miId). If information about this combination is absent from the LCD, then the snmpV3AcStatsNoGroups counter is incremented, and FALSE is returned to the caller. (3) The LCD (snmpV3AcTable) is consulted for information about the contextName, groupName and LoS. If information about this combination is absent from the LCD, then the snmpV3AcStatsNoViews counter is incremented, and FALSE is returned to the caller. (4) If the SNMPv2 viewType is the read, then the read-view is used for checking if the variableName is accessible. If access is allowed, then TRUE is returned to the caller. Otherwise the snmpV3AcStatsUnauthorizedAccesses counter is incremented and FALSE is returned to the caller. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 7] Draft Access Control Model (ACM) for SNMPv3 June 1997 (5) If the SNMPv2 viewType is the write, then the write-view is used for checking if the variableName is accessible. If access is allowed, then TRUE is returned to the caller. Otherwise the snmpV3AcStatsUnauthorizedAccesses counter is incremented and FALSE is returned to the caller. (6) If the SNMPv2 viewType is the notify, then the notify-view is used for checking if the variableName is accessible. If access is allowed, then TRUE is returned to the caller. Otherwise the snmpV3AcStatsUnauthorizedAccesses counter is incremented and FALSE is returned to the caller. Editor's note: We decided that a boolean would be returned. Maybe it is better to return a status_code which can have one of these values: otherError accessAllowed unknownContext noGroup noView accessNotAllowed Then the caller can generate the appropriate reportPDU (or tell the MPC to generate the appropriate reportPDU). End Editor's note Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 8] Draft Access Control Model (ACM) for SNMPv3 June 1997 4. Definitions SNMPV3-AC-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Unsigned32, BITS, MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION, TestAndIncr, RowStatus, StorageType, FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString, SnmpLoS, SnmpSecurityModel FROM SNMPv3-MIB; snmpV3AcMIB MODULE-IDENTITY LAST-UPDATED "9706180000Z" -- 18 June 1997, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@tis.com Subscribe: majordomo@tis.com In msg body: subscribe snmpv3 Chair: Russ Mundy Trusted Information Systems postal: 3060 Washington Rd Glenwood MD 21738 email: mundy@tis.com phone: 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-412-498 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 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 9] Draft Access Control Model (ACM) for SNMPv3 June 1997 " DESCRIPTION "The management information definitions for the SNMPv3 Access Control Model. " ::= { snmpModules 99 } -- Administrative assignments **************************************** snmpV3AcMIBObjects OBJECT IDENTIFIER ::= { snmpV3AcMIB 1 } snmpV3AcMIBConformance OBJECT IDENTIFIER ::= { snmpV3AcMIB 2 } -- Statistics for Access Control Checking **************************** snmpV3AcStats OBJECT IDENTIFIER ::= { snmpV3AcMIBObjects 1 } snmpV3AcStatsUnknownContexts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because they referenced a context that was not known to the engine. " ::= { snmpV3AcStats 1 } snmpV3AcStatsNoGroups OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because the security model independent ID (securityIdentity, miId) did not map a group in the snmpV3AcGroupTable. " ::= { snmpV3AcStats 2 } snmpV3AcStatsNoViews OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because the combination of contextName, groupName and LoS does not have an entry in the snmpV3AcTable at all. " ::= { snmpV3AcStats 3 } snmpV3AcStatsUnauthorizedAccesses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 10] Draft Access Control Model (ACM) for SNMPv3 June 1997 STATUS current DESCRIPTION "The total number of packets received by the SNMP engine which were dropped because the type of access requested is invalid or not authorized. " ::= { snmpV3AcStats 4 } -- Information about Mapping of miId into a group ******************** -- Editor's question: -- I have included the mapping table for the miId into a -- groupName into this MIB. I think that keeps the acces -- control nicely grouped together. Comments? -- End Editor's question. snmpV3AcGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3AcGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table that maps the Security Model Independent ID into a groupName which defines an acces control policy for a group of security identities. " ::= { snmpV3AcMIBObjects 2 } snmpV3AcGroupEntry OBJECT-TYPE SYNTAX SnmpV3AcGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in this table maps a miId into a groupName." INDEX { snmpV3AcSecModel, snmpV3AcMiId } ::= { snmpV3AcGroupTable 1 } SnmpV3AcGroupEntry ::= SEQUENCE { snmpV3AcSecModel SnmpV3SecurityModel, snmpV3AcMiId SnmpV3AdminString, snmpV3AcGroupName SnmpV3AdminString, snmpV3AcGroupStorageType StorageType, snmpV3AcGroupStatus RowStatus } snmpV3AcSecModel OBJECT-TYPE SYNTAX SnmpV3SecurityModel MAX-ACCESS not-accessible STATUS current DESCRIPTION "The security model, which is the first index in this table. " Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 11] Draft Access Control Model (ACM) for SNMPv3 June 1997 ::= { snmpV3AcGroupEntry 1 } snmpV3AcMiId OBJECT-TYPE SYNTAX SnmpV3AdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Security Model Independent ID (miId) for a particular security identity. It is used as a second index in this table. " ::= { snmpV3AcGroupEntry 2 } snmpV3AcGroupName OBJECT-TYPE SYNTAX SnmpV3AdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The groupName to which this miId belongs. This groupName represents a access control policy and is used as an index in the snmpV3AcTable. " ::= { snmpV3AcGroupEntry 3 } snmpV3AcGroupStorageType 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 } ::= { snmpV3AcGroupEntry 6 } snmpV3AcGroupStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of snmpV3AcGroupStatus for that row. " ::= { snmpV3AcGroupEntry 7 } -- Information about Local Contexts ********************************** snmpV3AcContextTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3AcContextEntry Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 12] Draft Access Control Model (ACM) for SNMPv3 June 1997 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 snmpV3AcTable. 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 SNMP engines in a manager role cannot configure contexts. Instead the table is meant to provide input to SNMP engines in a manager role such that they can properly configure the snmpV3AcTable to control access to all contexts in an SNMP engine operating in an agent role. " ::= { snmpV3AcMIBObjects 3 } snmpV3AcContextEntry OBJECT-TYPE SYNTAX SnmpV3AcContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular context." INDEX { snmpV3AcContextName } ::= { snmpV3AcContextTable 1 } SnmpV3AcContextEntry ::= SEQUENCE { snmpV3AcContextName SnmpV3AdminString } snmpV3AcContextName OBJECT-TYPE SYNTAX SnmpV3AdminString (SIZE(0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "A textual name uniquely identifying a particular context on a particular agent. " ::= { snmpV3AcContextEntry 1 } -- Information about Access Rights *********************************** snmpV3AcTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3AcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of group access rights configured in the Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 13] Draft Access Control Model (ACM) for SNMPv3 June 1997 local configuration datastore (LCD). Each entry is indexed by a contextName, a GroupName and a Level of Security (LoS). When checking if access is allowed, then 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 contextName. The procedure for this process depends on the value of snmpV3AcContextMatch: - exact In this case, the snmpV3AcContextName represents an exact contextName, and so the name must match exactly. - prefix In this case, the snmpV3AcContextName represents a prefix of a contextName, so that (a limited from of) wildcarding is possible. The value of snmpV3AcContextName must match with the first part of the contextName to which access is requested. For example, if we use a prefix contextName 'repeater', then both contexts named 'repeater1' and 'repeater2' are accessible. In case multiple entries match, then the entry with the longest snmpV3AcContextName wins. The second match to make is for the groupName. Here an exact match must be found. The 3rd match to make is for the LoS. Here an exact match must be found. " -- Editors Question to Keith: -- I have removed snmpV3AcContextName from the AcTable.... I was -- thinking that it has the same semantics as snmpV3AcContextName -- in the SnmpV3AcContextTable above. But now that we also allow -- for wildcarding here, now I am not so sure that the semantics -- are indeed the same. Should I define a snmpV2AcContextPrefix -- instead? -- End Editors Question ::= { snmpV3AcMIBObjects 4 } snmpV3AcEntry OBJECT-TYPE SYNTAX SnmpV3AcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An access right configured in the local configuration datastore (LCD) authorizing access to an SNMP context. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 14] Draft Access Control Model (ACM) for SNMPv3 June 1997 " INDEX { snmpV3AcContextName, snmpV3AcGroupName, snmpV3AcLoS } ::= { snmpV3AcTable 1 } SnmpV3AcEntry ::= SEQUENCE { snmpV3AcLoS SnmpV3LoS, snmpV3AcContextMatch INTEGER, snmpV3AcReadViewName SnmpV3AdminString, snmpV3AcWriteViewName SnmpV3AdminString, snmpV3AcNotifyViewName SnmpV3AdminString, snmpV3AcStorageType StorageType, snmpV3AcStatus RowStatus } snmpV3AcLoS OBJECT-TYPE SYNTAX SnmpV3LoS 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. " ::= { snmpV3AcEntry 1 } snmpV3AcContextMatch OBJECT-TYPE SYNTAX INTEGER { exact (0), -- exact match of context Name prefix (1) -- Only match to this prefix } MAX-ACCESS read-create STATUS current DESCRIPTION "If exact is set, then the contextName of the index part snmpV3AcContextName of this entry in this table represents a full contextName. If prefix is set, then the contextName of the index part snmpV3AcContextName of this entry in this table represents a partial contextName which acts as a prefix so that a simple form of wildcarding is possible. " ::= { snmpV3AcEntry 2 } snmpV3AcReadViewName OBJECT-TYPE SYNTAX SnmpV3AdminString MAX-ACCESS read-create STATUS current Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 15] Draft Access Control Model (ACM) for SNMPv3 June 1997 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 for which snmpV3AcViewName 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 snmpV3AcViewName, then no access is granted. Otherwise, this object is ignored and can take any value at the Access Control module's discretion, e.g., the empty string. " DEFVAL { ''H } -- the empty string ::= { snmpV3AcEntry 3 } snmpV3AcWriteViewName OBJECT-TYPE SYNTAX SnmpV3AdminString 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 for which snmpV3AcViewName 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 snmpV3AcViewName, then no access is granted. Otherwise, this object is ignored and can take any value at the Access Control module's discretion, e.g., the empty string. " DEFVAL { ''H } -- the empty string ::= { snmpV3AcEntry 4 } snmpV3AcNotifyViewName OBJECT-TYPE SYNTAX SnmpV3AdminString 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 for which snmpV3AcViewName 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 snmpV3AcViewName, then no access is granted. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 16] Draft Access Control Model (ACM) for SNMPv3 June 1997 Otherwise, this object is ignored and can take any value at the Access Control module's discretion, e.g., the empty string. " DEFVAL { ''H } -- the empty string ::= { snmpV3AcEntry 5 } snmpV3AcStorageType 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 } ::= { snmpV3AcEntry 6 } snmpV3AcStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of snmpV3AcStatus for that row. " ::= { snmpV3AcEntry 7 } -- Information about MIB views *************************************** -- Support for views having instance-level granularity is optional snmpV3AcViewTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3AcViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of locally defined MIB views. When an SNMP engine in the manager role wants to create a new MIB view, then it must first create an entry in the snmpV3AcViewTable, using a non-existing index-value for snmpV3AcViewName. If the creation of such an entry is successful, the SNMP engine in the manager role can then start creating entries in the snmpV3AcSubtreeFamiliyTable. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 17] Draft Access Control Model (ACM) for SNMPv3 June 1997 When deleting MIB views, it is strongly advised that first the related snmpV3AcSubtreeFamilityEntries are deleted from the snmpV3AcSubtreeFamiliyTable and that only upon completion of that deletion process the snmpV3AcViewEntry is deleted from the snmpV3AcViewTable. Furthermore, a manager should take great care to delete all the 'included' family entries before deleting any of the 'excluded' ones. Following these procedures there should be no collisions when multiple managers try to update the MIB views at an SNMP engine in an agent role. If managers do not follow these procedures then it is agent-implementation dependent as to what the result of possible collisions will be. " ::= { snmpV3AcMIBObjects 5 } snmpV3AcViewEntry OBJECT-TYPE SYNTAX SnmpV3AcViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular local MIB view." INDEX { snmpV3AcViewName } ::= { snmpV3AcViewTable 1 } SnmpV3AcViewEntry ::= SEQUENCE { snmpV3AcViewName SnmpV3AdminString, snmpV3AcViewStorageType StorageType, snmpV3AcViewStatus RowStatus } snmpV3AcViewName OBJECT-TYPE SYNTAX SnmpV3AdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An unique viewName that uniquely identifies a MIB viewEntry in this table. " ::= { snmpV3AcViewEntry 1 } snmpV3AcViewStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 18] Draft Access Control Model (ACM) for SNMPv3 June 1997 Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { snmpV3AcViewEntry 2 } snmpV3AcViewStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of snmpV3AcViewStatus for that row. " ::= { snmpV3AcViewEntry 3 } -- Subtree families of MIB views ************************************* snmpV3AcSubtreeFamilyTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3AcSubtreeFamilyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about families of subtrees within MIB views. Each MIB view is defined by two collections of view subtrees: the included view subtrees, and the excluded view subtrees. Every such 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 snmpV3AcSubtreeFamilyType in the entry whose value of snmpV3AcSubtreeFamilySubtree has the most sub-identifiers. If multiple entries match and have the same number of sub-identifiers, then the lexicographically greatest instance of snmpV3AcSubtreeFamilyType determines the inclusion or exclusion. An object instance's OBJECT IDENTIFIER X matches an Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 19] Draft Access Control Model (ACM) for SNMPv3 June 1997 active entry in this table when the number of sub-identifiers in X is at least as many as in the value of snmpV3AcSubtreeFamilySubtree for the entry, and each sub-identifier in the value of snmpV3AcSubtreeFamilySubtree matches its corresponding sub-identifier in X. Two sub-identifiers match either if the corresponding bit of snmpV3AcSubtreeFamilyMask is zero (the 'wild card' value), or if they are equal. A 'family' of view subtrees is the set of subtrees defined by a particular combination of values of snmpV3AcSubtreeFamilySubtree and snmpV3AcSubtreeFamilyMask. In the case where no 'wild card' is defined in snmpV3AcSubtreeFamilyMask, the family of view subtrees reduces to a single view subtree. When an SNMP engine in the manager role wants to create a new MIB view, then it should first create an entry in the snmpV3AcViewTable, using a non-existing index-value for snmpV3AcViewName. If the creation of such an entry is successful, the SNMP engine in the manager role can then start creating entries in the snmpV3AcSubtreeFamiliyTable. When deleting MIB views, it is strongly advised that first the related snmpV3AcSubtreeFamilityEntries are deleted from the snmpV3AcSubtreeFamiliyTable and that only upon completion of that deletion process the snmpV3AcViewEntry is deleted from the snmpV3AcViewTable. Following these procedures there should be no collisions when multiple managers try to update the MIB views at an SNMP engine in an agent role. " ::= { snmpV3AcMIBObjects 6 } snmpV3AcSubtreeFamilyEntry OBJECT-TYPE SYNTAX SnmpV3AcSubtreeFamilyEntry 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. The MIB view must exist (i.e., be represented by a conceptual row in the snmpV3AcViewTable) before any subtree families can be defined for it. Implementations must not restrict the number of Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 20] Draft Access Control Model (ACM) for SNMPv3 June 1997 families of view subtrees for a given MIB view, except as dictated by resource constraints on the overall number of entries in the snmpV3AcSubtreeFamilyTable. The value of snmpV3AcViewName in this INDEX clause of this table identifies the MIB view in which this subtree family exists. A MIB view for which there are no conceptual rows in this table is the empty set of view subtrees. " INDEX { snmpV3AcViewName, IMPLIED snmpV3AcSubtreeFamilySubtree } ::= { snmpV3AcSubtreeFamilyTable 1 } SnmpV3AcSubtreeFamilyEntry ::= SEQUENCE { snmpV3AcSubtreeFamilySubtree OBJECT IDENTIFIER, snmpV3AcSubtreeFamilyMask OCTET STRING, snmpV3AcSubtreeFamilyType INTEGER, snmpV3AcSubtreeFamilyStorageType StorageType, snmpV3AcSubtreeFamilyStatus RowStatus } snmpV3AcSubtreeFamilySubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MIB subtree which when combined with the corresponding instance of snmpV3AcSubtreeFamilyMask defines a family of view subtrees. " ::= { snmpV3AcSubtreeFamilyEntry 1 } snmpV3AcSubtreeFamilyMask 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 snmpV3AcSubtreeFamilySubtree, defines a family of view subtrees. Each bit of this bit mask corresponds to a sub-identifier of snmpV3AcSubtreeFamilySubtree, 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 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 21] Draft Access Control Model (ACM) for SNMPv3 June 1997 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 snmpV3AcSubtreeFamilySubtree, either: the i-th bit of snmpV3AcSubtreeFamilyMask is 0, or the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of snmpV3AcSubtreeFamilySubtree. If the value of this bit mask is M bits long and there are more than M sub-identifiers in the corresponding instance of snmpV3AcSubtreeFamilySubtree, 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 snmpV3AcSubtreeFamilySubtree. " DEFVAL { ''H } ::= { snmpV3AcSubtreeFamilyEntry 2 } snmpV3AcSubtreeFamilyType OBJECT-TYPE SYNTAX INTEGER { included(1), excluded(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The indication of whether the corresponding instances of snmpV3AcSubtreeFamilySubtree and snmpV3AcSubtreeFamilyMask define a family of view subtrees which is included in or excluded from the MIB view. " DEFVAL { included } ::= { snmpV3AcSubtreeFamilyEntry 3 } Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 22] Draft Access Control Model (ACM) for SNMPv3 June 1997 snmpV3AcSubtreeFamilyStorageType 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. An SNMP engine in the manager role is advised to use the same value for this row as the value used in the corresponding row in the snmpV3AcViewTable. " DEFVAL { nonVolatile } ::= { snmpV3AcSubtreeFamilyEntry 4 } snmpV3AcSubtreeFamilyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of snmpV3AcSubtreeFamilyStatus for that row. An SNMP engine in the manager role is advised to use the same value for this row as the value used in the corresponding row in the snmpV3AcViewTable. " ::= { snmpV3AcSubtreeFamilyEntry 5 } -- Conformance information ******************************************* snmpV3AcMIBCompliances OBJECT IDENTIFIER ::= { snmpV3AcMIBConformance 1 } snmpV3AcMIBGroups OBJECT IDENTIFIER ::= { snmpV3AcMIBConformance 2 } -- Compliance statements ********************************************* snmpV3AcMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMPv3 ACM configuration MIB. " MODULE -- this module MANDATORY-GROUPS { snmpV3AcBasicGroup } Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 23] Draft Access Control Model (ACM) for SNMPv3 June 1997 OBJECT snmpV3AcContextMatch MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3AcReadViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3AcWriteViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3AcNotifyViewName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3AcStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3AcStatus MIN-ACCESS read-only DESCRIPTION "Create access to the snmpV3AcViewTable is not required. " OBJECT snmpV3AcViewStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3AcViewStatus MIN-ACCESS read-only DESCRIPTION "Create access to the snmpV3AcViewTable is not required. " OBJECT snmpV3AcSubtreeFamilyMask WRITE-SYNTAX OCTET STRING (SIZE (0)) MIN-ACCESS read-only DESCRIPTION "Support for configuration via SNMP of subtree families defined using wild-cards is not required. " OBJECT snmpV3AcSubtreeFamilyType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3AcSubtreeFamilyStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 24] Draft Access Control Model (ACM) for SNMPv3 June 1997 OBJECT snmpV3AcSubtreeFamilyStatus MIN-ACCESS read-only DESCRIPTION "Create access to the snmpV3AcSubtreeFamilyTable is not required. " ::= { snmpV3AcMIBCompliances 1 } -- Units of conformance ********************************************** snmpV3AcBasicGroup OBJECT-GROUP OBJECTS { snmpV3AcStatsUnknownContexts, snmpV3AcStatsNoGroups, snmpV3AcStatsNoViews, snmpV3AcStatsUnauthorizedAccesses, -- length 33 snmpV3AcGroupName, snmpV3AcGroupStorageType, snmpV3AcGroupStatus, snmpV3AcContextName, snmpV3AcReadViewName, snmpV3AcWriteViewName, snmpV3AcNotifyViewName, snmpV3AcStorageType, snmpV3AcStatus, snmpV3AcViewStorageType, snmpV3AcViewStatus, snmpV3AcSubtreeFamilyMask, snmpV3AcSubtreeFamilyType, snmpV3AcSubtreeFamilyStorageType, -- length 32 snmpV3AcSubtreeFamilyStatus } STATUS current DESCRIPTION "A collection of objects providing for remote configuration of an SNMP engine which implements the SNMPv3 Access Control Model (ACM). " ::= { snmpV3AcMIBGroups 1 } END Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 25] Draft Access Control Model (ACM) for SNMPv3 June 1997 5. Security Considerations 5.1 Recommended Practices This document is meant for use in the SNMP architecture. The Access Control Model (ACM) described in this document controls 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 securityIdentities. These securityIdentities are mapped into one or more groups in the SNMPv3 Access Control subsystem. - Level of Security (LoS) used for the transmission of an SNMP message. When the 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 GroupNames are used to give access to a group of zero, one or more securityIdentities. Within the ACM, a groupName is considered to exist if that groupName is used (as an index) in a row in the snmpV3AcTable. By mapping a securityIdentity into a group, a Management System can add/delete securityIdentities to/from a group. 5.3 Conformance Conformance rules are described in the SNMP architecture document [SNMP-ARCH]. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 26] Draft Access Control Model (ACM) for SNMPv3 June 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 27] Draft Access Control Model (ACM) for SNMPv3 June 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. [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-ACM] The SNMPv3 Working Group, Wijnen, B., Harrington, D., "Access Control Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", draft-ietf-snmpv3-acm-00.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, March 1997. [SNMPv3-USEC] 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-usec-01.txt, June 1997. Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 28] Draft Access Control Model (ACM) for SNMPv3 June 1997 APPENDIX A - Installation A.1. Installation Parameters During installation, an SNMPv3 engine acting in an authoritative role is configured with several parameters. These include for the Access Control module: (1) A security posture The choice of security posture determines the extent of the view configured for unauthenticated access. One of three possible choices is selected: minimum-secure, semi-secure, or very-secure. (2) A default context One entry in the snmpV3AcContextTable with a contextName of "" (the empty string, representing the default context. Editor's note: If we do keep the groupTable, then we also need an entry in the groupTable for group public. It should have a miId of "public" for USEC that maps into groupName "public" End Editor's note. (3) Three entries in the snmpV3AcTable as follows: - One entry to be used for unauthenticated access: no privacy support privacy support ------------------ --------------- snmpV3AcContextName "" "" snmpV3AcGroupName "public" "public" snmpV3AcLoS noAuth/noPriv noAuth/noPriv snmpV3AcReadViewName "restricted" "restricted" snmpV3AcWriteViewName "" "" snmpV3AcNotifyViewName "restricted" "restricted" snmpV3AcStorageType permanent permanent snmpV3AcStatus active active - One entry to be used for authenticated access but without privacy: no privacy support privacy support ------------------ --------------- snmpV3AcContextName "" "" snmpV3AcGroupName "public" "public" snmpV3AcLoS Auth/noPriv Auth/noPriv Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 29] Draft Access Control Model (ACM) for SNMPv3 June 1997 snmpV3AcReadViewName "all" "all" snmpV3AcWriteViewName "all" "all" snmpV3AcNotifyViewName "all" "all" snmpV3AcStorageType permanent permanent snmpV3AcStatus active active - One entry to be used for authenticated access with privacy: no privacy support privacy support ------------------ --------------- snmpV3AcContextName "" snmpV3AcGroupName "public" snmpV3AcLoS Auth/Priv snmpV3AcReadViewName "all" snmpV3AcWriteViewName "all" snmpV3AcNotifyViewName "all" snmpV3AcStorageType permanent snmpV3AcStatus active (4) Two views depending on the security posture. - One view (theview) for authenticated access: - the MIB view is the following subtree: "internet" [RFC1902] Editor's note: I picked this up from the RFC1910. I have experience myself that MIBs were defined outside the internet subtree, so maybe this should just be "iso" End Editor's note. - A second view (the view) for unauthenticated access. This view is configured according to the selected security posture: - For the "very-secure" posture: the MIB view is the union of these subtrees: "snmp" [RFC1907] "snmpEngine" [SNMPv3-USEC] "snmpV3Stats" [SNMPv3-MPC] "snmpV3AcStats" [SNMPv3-ACM] - For the "semi-secure" posture: the MIB view is the union of these subtrees: "snmp" [RFC1907] "snmpEngine" [SNMPv3-USEC] "snmpV3Stats" [SNMPv3-MPC] Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 30] Draft Access Control Model (ACM) for SNMPv3 June 1997 "snmpV3AcStats" [SNMPv3-ACM] "system" [RFC1907] - For the "minimum-secure" posture: the MIB view is the following subtree. "internet" [RFC1902] - Access rights to allow: - read-notify access for LoS "noAuth" on behalf of security entities that belong to the group "public" to the MIB view in the context with contextName "". - read-write-notify access for LoS "auth" on behalf of security entities that belong to the group "public" to the MIB view in the context with contextName "". - if privacy is supported, read-write-notify access for LoS "auth" on behalf of security entities that belong to the group "public" to the MIB view in the context with contextName "". -- Editor's note: If we find it useful (I do) then I will also work out the entries in the viewTable and viewSubtreeFamilyTable so that we have the above views defined. -- End Editor's note Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 31] Draft Access Control Model (ACM) for SNMPv3 June 1997 Table of Contents 0.1 Issues 2 0.2 Change Log 2 1. Introduction 3 1.2 Access Control 3 1.3 Local Configuration Datastore 3 2. Elements of the Model 5 2.1 Groups 5 2.2 Level of Security (LoS) 5 2.3 Contexts 5 2.4 Access Policy 5 3. Elements of Procedure 7 3.1 Processing the is_access_allowed service request 7 4. Definitions 9 5. Security Considerations 26 5.1 Recommended Practices 26 5.2 Defining Groups 26 5.3 Conformance 26 6. Editor's Addresses 27 7. Acknowledgements 27 8. References 28 A.1. Installation Parameters 29 Wijnen/Presuhn/McCloghrie Expires December 1997 [Page 32]