View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
obsoleted by
- rfc-3415 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-2275 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
Extracted elements (25)
The vacmAccessTable uses a context prefix match (exact or prefix) rather than requiring an exact context name, enabling a single access entry to grant rights across a set of contexts sharing a common name prefix. This allows simple wildcarding without a full pattern-matching mechanism.
The ViewTreeFamily mask mechanism was introduced because specifying all columns of a single conceptual MIB row would otherwise require one separate view subtree per column. By allowing wildcard sub-identifiers via a bit mask, many structurally similar subtrees can be aggregated into a single vacmViewTreeFamilyTable entry.
Three initial security configurations are specified (initial-no-access-configuration, initial-semi-security-configuration, initial-minimum-security-configuration) to allow deployers to choose the level of bootstrap access appropriate to their environment, ranging from no pre-configured access to full internet subtree access for unauthenticated principals.
The presence of entries in vacmContextTable and entries in vacmAccessTable are independent: a context in vacmContextTable need not be referenced by any vacmAccessTable entry, and a contextName referenced in vacmAccessTable need not currently exist as an entry in vacmContextTable.
An authoritative SNMP engine that supports VACM SHOULD be configured with initial parameters at installation time, including a default context, an 'initial' group entry in vacmSecurityToGroupTable, appropriate entries in vacmAccessTable, and predefined 'internet' and 'restricted' MIB views.
For a VACM implementation to be conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according to vacmMIBCompliance. It also SHOULD implement the initial configuration described in Appendix A.
vacmContextTable MUST be made accessible via the default context so that Command Responder applications have a standard way of retrieving locally available context information.
When an implementation creates an entry for instance-level access control in vacmViewTreeFamilyTable but does not support instance-level granularity, it MUST return an inconsistentName error.
When selecting an entry from vacmAccessTable among multiple candidates, entries with a securityModel exactly matching the request take priority over 'any', entries with exact contextPrefix match take priority over prefix match, longer contextPrefixes take priority over shorter ones, and finally the entry with the highest securityLevel is selected.
A group is a set of zero or more <securityModel, securityName> tuples. The combination of a securityModel and securityName maps to at most one groupName, identified via the vacmSecurityToGroupTable. Groups define uniform access rights for all securityNames they contain.
A ViewTreeFamily pairs a family name (OBJECT IDENTIFIER) with a family mask (bit string). Each bit of the mask corresponds to an OID sub-identifier; a 0 bit is a wildcard matching any sub-identifier value, while a 1 bit requires an exact match. This allows a single entry to represent a family of subtrees such as all columns in a conceptual row.
An access policy is defined per (groupName, contextName, securityModel, securityLevel) tuple and specifies three MIB views: a read-view for retrieval operations, a write-view for modification operations, and a notify-view for notification content. Each view may independently be empty (no access) or reference a configured vacmViewTreeFamilyTable view.
The isAccessAllowed service primitive is the sole abstract interface of the View-based Access Control Model. It takes securityModel, securityName, securityLevel, viewType (read/write/notify), contextName, and variableName as inputs, and returns statusInformation of accessAllowed, notInView, noSuchView, noSuchContext, noGroupName, noAccessEntry, or otherError.
vacmAccessTable is indexed by (vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel, vacmAccessSecurityLevel) and stores vacmAccessContextMatch (exact or prefix), vacmAccessReadViewName, vacmAccessWriteViewName, and vacmAccessNotifyViewName. An empty viewName string means no access is granted for that access type.
vacmContextTable lists all locally available SNMP contexts by contextName (SnmpAdminString, SIZE 0..32). The empty contextName represents the default context. The table is read-only and must be accessible via the default context; it changes dynamically only when management instrumentation recognizes more or fewer contexts.
vacmSecurityToGroupTable maps (vacmSecurityModel, vacmSecurityName) index pairs to a vacmGroupName (SnmpAdminString, SIZE 1..32). A newly created row remains notReady until vacmGroupName is set. The vacmSecurityModel index MUST NOT take the 'any' (0) value.
vacmViewSpinLock is an advisory TestAndIncr lock that cooperating SNMP Command Generator applications should use when creating or modifying MIB views to avoid concurrent-write collisions. Because it is advisory, its use is not enforced by the engine.
vacmViewTreeFamilyTable defines MIB views as sets of included and excluded view subtree families. Each entry is indexed by (vacmViewTreeFamilyViewName, vacmViewTreeFamilySubtree) and carries a vacmViewTreeFamilyMask and vacmViewTreeFamilyType (included/excluded). When multiple entries match an OID, the entry with the most sub-identifiers in its subtree takes precedence; ties are broken lexicographically by vacmViewTreeFamilyType.
The SNMP-VIEW-BASED-ACM-MIB is registered under snmpModules 16 (OID 1.3.6.1.6.3.16). It defines the vacmContextTable, vacmSecurityToGroupTable, vacmAccessTable, and vacmViewTreeFamilyTable for remote configuration of VACM parameters.
For securityLevel noAuthNoPriv, all groups are functionally equivalent because the assumption that the securityName has been authenticated does not hold; the Access Control module accepts the securityName as-is without re-authenticating it.
The grouping of <securityModel, securityName> tuples in vacmSecurityToGroupTable does not account for securityLevel. Security administrators must therefore use the securityLevel index in vacmAccessTable to enforce separation between noAuthNoPriv, authNoPriv, and authPriv access rights.
The objects in SNMP-VIEW-BASED-ACM-MIB control access to all MIB data accessible via the SNMP engine and are sensitive in many environments. Both read and write access to these objects must be closely controlled using appropriately configured access control models.
When creating or deleting entries in vacmViewTreeFamilyTable, the recommended sequence must be followed: create 'excluded' entries before 'included' entries, and delete 'included' entries before 'excluded' entries. Reversing this order can result in unintended access being granted during the transition.
The isAccessAllowed procedure follows five sequential steps: (1) look up contextName in vacmContextTable — absent yields noSuchContext; (2) look up (securityModel, securityName) in vacmSecurityToGroupTable — absent yields noGroupName; (3) look up (groupName, contextName, securityModel, securityLevel) in vacmAccessTable — absent yields noAccessEntry; (4) select the view by viewType — empty viewName yields noSuchView; (5) check variableName against the selected MIB view — not in view yields notInView, otherwise return accessAllowed.
vacmViewTreeFamilyMask is encoded as an OCTET STRING of SIZE 0..16. The most significant bit of the i-th octet corresponds to the (8i-7)-th OID sub-identifier of vacmViewTreeFamilySubtree. When the mask is shorter than the subtree length, it is implicitly extended with ones; a zero-length mask therefore acts as all-ones (exact match, no wildcarding).