View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-2575 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
also
- std-62
Extracted elements (27)
A ViewTreeFamily pairs an OID (family name) with a bitmask to concisely represent families of view subtrees. This avoids enumerating a very large number of individual subtrees when specifying, for example, all columns in a conceptual row — which appear in separate OID subtrees with similar formats that can be aggregated into one structure.
Appendix A prescribes three installation security configurations: initial-minimum-security-configuration (unauthenticated access to all of 1.3.6.1), initial-semi-security-configuration (unauthenticated access restricted to system, snmp, snmpEngine, snmpMPDStats, usmStats subtrees only), and initial-no-access-configuration (no pre-configured access). This graduated bootstrap posture lets operators choose their risk tolerance at deployment.
Instance-level granularity in MIB views is optional because it may come at a high performance cost. Managers should avoid requesting instance-level configurations unnecessarily; implementations that do not support it must reject such entries with inconsistentName.
The presence of entries in vacmContextTable and vacmAccessTable are deliberately independent: a context in vacmContextTable need not be referenced by any vacmAccessTable entry, and a context referenced in vacmAccessTable need not currently exist in vacmContextTable. This allows pre-configuration of access rights before contexts are instantiated.
Support for vacmViewTreeFamilyMask values of non-zero length (wildcard masks) is optional. Implementations that do not support wildcard masks may make vacmViewTreeFamilyMask effectively read-only with a WRITE-SYNTAX restricted to OCTET STRING (SIZE 0), as reflected in the vacmMIBCompliance MODULE-COMPLIANCE statement.
Write access to all vacmAccessTable columns (vacmAccessContextMatch, vacmAccessReadViewName, vacmAccessWriteViewName, vacmAccessNotifyViewName, vacmAccessStorageType, vacmAccessStatus) and all vacmViewTreeFamilyTable columns is not required for compliance — an implementation may treat all of these as read-only.
For an implementation of VACM to be conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according to vacmMIBCompliance (vacmBasicGroup is mandatory) and SHOULD implement the initial configuration described in Appendix A.
If a create request for a vacmViewTreeFamilyEntry would provide instance-level granularity and the implementation does not support instance-level granularity, an inconsistentName error MUST be returned.
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 vacmViewTreeFamilyTable.
The vacmAccessTable entry selection algorithm narrows candidates by groupName, context match (exact or prefix), and securityModel (specific beats 'any'), and requires vacmAccessSecurityLevel to be less than or equal to the requested level. Among remaining ties, preference is: exact securityModel > longest contextPrefix > highest securityLevel.
When creating MIB views, 'excluded' vacmViewTreeFamilyEntries SHOULD be created first and then 'included' entries. When deleting, 'included' entries SHOULD be deleted first and then 'excluded' entries, to avoid temporarily granting unwanted access during transitions.
A VACM group is a set of zero or more <securityModel, securityName> tuples mapped to a groupName via the vacmSecurityToGroupTable. The combination of a securityModel and securityName maps to at most one group; the groupName then selects an access policy in the vacmAccessTable.
An access policy for a group in a given context is expressed as three named MIB views: a read-view (for Read Class PDUs), a write-view (for Write Class PDUs), and a notify-view (for Notification Class PDUs). An empty-string viewName means no access is granted for that operation type.
The isAccessAllowed service primitive is the abstract interface to VACM, taking securityModel, securityName, securityLevel, viewType (read/write/notify), contextName, and variableName as inputs. It returns one of: accessAllowed, notInView, noSuchView, noSuchContext, noGroupName, noAccessEntry, or otherError.
The vacmAccessContextMatch object (exact(1) or prefix(2)) controls whether a contextName must exactly match vacmAccessContextPrefix or merely start with it, enabling a simple form of wildcarding for context-name matching in access entries.
The vacmAccessTable stores access rights indexed by (vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel, vacmAccessSecurityLevel). Each entry specifies vacmAccessReadViewName, vacmAccessWriteViewName, and vacmAccessNotifyViewName; an empty string for any view means no access is granted for that operation.
The vacmContextTable (read-only, not configurable via SNMP) lists locally available contexts by vacmContextName (SnmpAdminString, SIZE 0..32). The empty contextName represents the default context. The table must be accessible via the default context.
The vacmSecurityToGroupTable maps a <vacmSecurityModel (1..2147483647, excluding 'any'=0), vacmSecurityName (SIZE 1..32)> pair to a vacmGroupName (SIZE 1..32). A row cannot be made active until vacmGroupName is set; the row status remains 'notReady' until then.
The vacmViewSpinLock (TestAndIncr) is an advisory lock enabling cooperating SNMP Command Generators to coordinate creation and modification of MIB views. It prevents races when multiple managers modify views concurrently; its use is not enforced by the protocol.
The vacmViewTreeFamilyTable defines MIB views as sets of included and excluded OID subtree families. Each entry pairs a vacmViewTreeFamilySubtree (OBJECT IDENTIFIER) with a vacmViewTreeFamilyMask (OCTET STRING, SIZE 0..16) and vacmViewTreeFamilyType of included(1) or excluded(2). The longest-matching subtree entry determines inclusion or exclusion.
This document defines the SNMP-VIEW-BASED-ACM-MIB module registered at snmpModules 16 (OID 1.3.6.1.6.3.16). The mandatory vacmBasicGroup conformance group covers: vacmContextName, vacmGroupName, vacmSecurityToGroupStorageType, vacmSecurityToGroupStatus, vacmAccess* columns, vacmViewSpinLock, and vacmViewTreeFamily* columns.
At securityLevel noAuthNoPriv, all groups are effectively equivalent because the assumption that the securityName has been authenticated does not hold. Security administrators must use the securityLevel index in vacmAccessTable to enforce separation between unauthenticated and authenticated access.
The grouping of <securityModel, securityName> tuples in vacmSecurityToGroupTable does not consider securityLevel. It is the security administrator's responsibility to use the securityLevel index in vacmAccessTable to separate noAuthNoPriv, authNoPriv, and authPriv access rights.
The SNMP-VIEW-BASED-ACM-MIB objects control access to all MIB data accessible via the SNMP engine and are considered sensitive. Both read and write access to these MIB objects must be closely controlled using appropriately configured access control models.
VACM assumes the calling module has already ensured authentication and privacy as required by the securityLevel being passed; the Access Control module performs no further authentication of securityName on its own.
The isAccessAllowed procedure follows five ordered steps: (1) look up contextName in vacmContextTable or return noSuchContext; (2) look up (securityModel, securityName) in vacmSecurityToGroupTable or return noGroupName; (3) look up (groupName, contextName, securityModel, securityLevel) in vacmAccessTable or return noAccessEntry; (4) select viewName by viewType or return noSuchView if empty; (5) check variableName is in the MIB view and return accessAllowed or notInView.
The vacmViewTreeFamilyMask is an OCTET STRING of SIZE 0..16. Each bit corresponds to a sub-identifier of vacmViewTreeFamilySubtree: a '1' bit requires an exact match; a '0' bit is a wildcard (any sub-identifier value matches). If the mask is shorter than the subtree OID, it is implicitly extended with 1's; a zero-length mask results in all-1's (no wildcarding).