View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
obsoleted by
- rfc-2575 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-2265 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
Extracted elements (29)
For securityLevel noAuthNoPriv, all groups are effectively equivalent since authentication of the securityName cannot be assumed. The access table selection algorithm notes this limitation explicitly to alert operators that noAuthNoPriv entries provide weak access guarantees regardless of groupName.
MIB views are defined as families of view subtrees (name + bitmask) rather than explicit lists of OIDs because many access-control scenarios (e.g., all columns of a conceptual row) would otherwise require an impractically large number of individual subtree entries. The family abstraction aggregates these into one structure.
The vacmContextTable is made read-only and not configurable via SNMP. It is populated automatically by the managed system as contexts appear or disappear, ensuring the table always reflects actual local state rather than an administratively asserted list.
Two predefined MIB views are specified for initial installation: the '<internet>' view (subtree 1.3.6.1) for authenticated access, and the '<restricted>' view limited to system/snmp/engine/MPD/USM statistics subtrees for semi-secure unauthenticated access. This tiered default prevents unauthenticated principals from reading sensitive configuration objects.
Support for instance-level access control granularity (i.e., non-zero-length vacmViewTreeFamilyMask values) is optional. Implementations that do not support wildcard masks make vacmViewTreeFamilyMask read-only with WRITE-SYNTAX restricted to SIZE(0). Managers should avoid requesting such configurations unnecessarily due to the potential performance cost.
The presence of entries in vacmContextTable and vacmAccessTable is independent: a context listed in vacmContextTable need not be referenced by any access entry, and a context referenced in vacmAccessTable need not currently exist in vacmContextTable.
A conformant implementation of the View-based Access Control Model MUST implement the SNMP-VIEW-BASED-ACM-MIB and SHOULD implement the initial configuration described in Appendix A.
An authoritative SNMP engine supporting VACM SHOULD be configured during installation with one of three initial security configurations (initial-minimum-security, initial-semi-security, or initial-no-access), including pre-populated entries in vacmContextTable, vacmSecurityToGroupTable, vacmAccessTable, and vacmViewTreeFamilyTable as specified in Appendix A.
If a create request for a vacmViewTreeFamilyEntry specifies instance-level access control granularity and the implementation does not support it, an inconsistentName error MUST be returned.
Implementations MUST NOT restrict the number of view subtree families for a given MIB view except as dictated by resource constraints on the total number of entries in vacmViewTreeFamilyTable.
When selecting an entry from vacmAccessTable with multiple candidates, the algorithm first prefers entries with an identical securityModel over 'any', then prefers entries with an identical contextPrefix, then prefers longer contextPrefixes, then selects the entry with the highest securityLevel.
A group is a set of zero or more <securityModel, securityName> tuples identified by a groupName. The combination of securityModel and securityName maps to at most one group, and all members share the same access rights.
A ViewTreeFamily pairs a family name (OBJECT IDENTIFIER) with a family mask (bit string). An OID belongs to the family if it has at least as many sub-identifiers as the family name and each sub-identifier matches wherever the corresponding mask bit is non-zero.
Access rights are differentiated by securityLevel (noAuthNoPriv, authNoPriv, authPriv). The securityLevel is passed as input to the Access Control module and determines which vacmAccessTable entry applies.
An access policy for a group in a given context is defined by three MIB views: read-view (for Get/GetNext/GetBulk), write-view (for Set), and notify-view (for Inform/SNMPv2-Trap). Empty viewName (zero-length) means no access is granted.
The isAccessAllowed abstract service primitive takes securityModel, securityName, securityLevel, viewType (read/write/notify), contextName, and variableName as inputs and returns statusInformation indicating accessAllowed, notInView, noSuchView, noSuchContext, noGroupName, noAccessEntry, or otherError.
vacmAccessContextMatch controls whether contextName must exactly match vacmAccessContextPrefix (value exact(1)) or only share the same starting octets (value prefix(2)), enabling simple wildcard context matching.
vacmAccessTable is indexed by (vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel, vacmAccessSecurityLevel) and stores vacmAccessContextMatch (exact/prefix), read/write/notify view names, StorageType, and RowStatus. An entry with the highest matching securityLevel wins when multiple entries qualify.
vacmContextTable lists locally available SNMP contexts by contextName (SnmpAdminString, SIZE 0..32). It is read-only and must be accessible via the default context; the empty contextName represents the default context.
vacmSecurityToGroupTable maps combinations of vacmSecurityModel and vacmSecurityName (index) to a vacmGroupName (SIZE 1..32). The securityModel value 0 ('any') is not permitted as an index.
vacmViewSpinLock (TestAndIncr) is an advisory lock to coordinate concurrent SNMP Command Generator applications creating or modifying MIB views. Its use is not enforced but is strongly recommended to avoid collisions.
vacmViewTreeFamilyTable holds included and excluded view subtree families indexed by (vacmViewTreeFamilyViewName, vacmViewTreeFamilySubtree). When multiple entries match an OID, the entry with the most sub-identifiers in its subtree takes precedence; ties are broken by the lexicographically greatest vacmViewTreeFamilyType.
This document defines the SNMP-VIEW-BASED-ACM-MIB module assigned OID snmpModules 16 (correcting a clerical error from RFC 2265 which is obsoleted by this document). The MIB includes vacmContextTable, vacmSecurityToGroupTable, vacmAccessTable, and vacmViewTreeFamilyTable.
vacmBasicGroup (OBJECT-GROUP) is the single mandatory conformance group defined in this MIB, encompassing vacmContextName, vacmGroupName, vacmSecurityToGroupStorageType/Status, all vacmAccess* view name and control objects, vacmViewSpinLock, and all vacmViewTreeFamily* objects.
The VACM Access Control module assumes the calling module has already ensured authentication and privacy as specified by the passed securityLevel; VACM performs no additional authentication of the securityName itself.
The vacmSecurityToGroupTable grouping of <securityModel, securityName> tuples does not account for securityLevel. Security administrators must use the securityLevel index in vacmAccessTable to properly separate noAuthNoPriv access from authNoPriv and authPriv access; failure to do so can grant unauthenticated principals write access.
When creating entries in vacmViewTreeFamilyTable it is important to create 'excluded' entries first and then 'included' entries; when deleting, 'included' entries should be deleted first and 'excluded' entries last. Reversing this order may grant unwanted access during the transition.
The isAccessAllowed procedure proceeds through five sequential steps: (1) check vacmContextTable for contextName, returning noSuchContext if absent; (2) look up vacmSecurityToGroupTable for groupName, returning noGroupName if absent; (3) look up vacmAccessTable for the access entry, returning noAccessEntry if absent; (4) select the MIB view by viewType, returning noSuchView for empty viewName; (5) check variableName membership in the view, returning notInView or accessAllowed.
vacmViewTreeFamilyMask is an OCTET STRING of 0..16 bytes where each bit corresponds to a sub-identifier of vacmViewTreeFamilySubtree; a '1' bit requires exact match and a '0' bit is a wildcard. If the mask is shorter than the subtree length it is extended with 1's; a zero-length mask results in all-1's (no wildcards).