RFC 2265
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) ✨
okay bestie, this is RFC 2265 🎀 It's a Standards Track doc from January 1998, written by B. Wijnen (IBM T. J. Watson Research), R. Presuhn (BMC Software, Inc.), and K. McCloghrie (Cisco Systems, Inc.). The whole thing is about the View-based Access Control Model (VACM) for SNMP, which is literally who gets to see and touch which management info 👑 The title block doesn't say it obsoletes or updates anything, so this one is standing on its own 💅
Status of this Memo 📋
okay so this part is the legal-ish stuff, but it's still important! It says this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want the current standardization state of this protocol, go check the "Internet Official Protocol Standards" (STD 1) ✨ And distribution of this memo is unlimited, so share away 🦋
Copyright Notice
Copyright (C) The Internet Society (1997). All Rights Reserved. 🌸
Abstract
so the abstract is giving "here's the whole vibe" 💖 This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. It also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model 🧚
Table of Contents
1. Introduction 2
1.2. Access Control 2
1.3. Local Configuration Datastore 3
2. Elements of the Model 3
2.1. Groups 3
2.2. securityLevel 4
2.3. Contexts 4
2.4. MIB Views and View Families 4
2.4.1. View Subtree 5
2.4.2. ViewTreeFamily 5
2.5. Access Policy 6
3. Elements of Procedure 6
3.1. Overview of isAccessAllowed Process 8
3.2. Processing the isAccessAllowed Service Request 9
4. Definitions 10
5. Intellectual Property 26
6. Acknowledgements 27
7. Security Considerations 28
7.1. Recommended Practices 28
7.2. Defining Groups 29
7.3. Conformance 29
8. References 29
9. Editors' Addresses 30
A.1. Installation Parameters 31
B. Full Copyright Statement 361. Introduction 🌈
okay so first things first, the SNMP engine is made of four pieces. Here they are, in order:
1) a Dispatcher
2) a Message Processing Subsystem,
3) a Security Subsystem, and
4) an Access Control Subsystem.Applications make use of the services of these subsystems ✨
It's really important to get the SNMP architecture and its terminology down, because that's how you figure out where VACM sits in the architecture and how it talks to the other subsystems 🧠 The reader is expected to have read and understood the description and terminology of the SNMP architecture, as defined in [RFC2261]. No skipping, bestie 😭
The Access Control Subsystem of an SNMP engine is in charge of checking whether a specific type of access (read, write, notify) to a particular object (instance) is allowed 🔥
So this document's whole purpose is to define one specific model of the Access Control Subsystem, called the View-based Access Control Model. Just to be clear, it's not necessarily the only Access Control Model out there 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the official capital-letter rule words, so read them the way [RFC2119] says 🫶
1.2. Access Control 🔐
Access Control happens (either implicitly or explicitly) in an SNMP entity when it processes SNMP retrieval or modification request messages from another SNMP entity. For example, a Command Responder application applies Access Control when it processes requests it got from a Command Generator application 💖 These requests cover GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations.
Access Control also happens in an SNMP entity when an SNMP notification message gets generated (by a Notification Originator application). Those notification messages cover InformRequest and SNMPv2-Trap operations 🦋
The View-based Access Control Model defines a set of services that an application (like a Command Responder or a Notification Originator application) can use to check access rights. It's the application's job to make the right service calls for access checking, so the app is the one doing the work here 👑
1.3. Local Configuration Datastore 🗄️
To implement the model in this document, an SNMP entity has to keep track of access rights and policies. That info is part of the SNMP engine's Local Configuration Datastore (LCD). Check [RFC2261] for the definition of LCD 🌸
Now, so an SNMP entity's LCD can be configured remotely, parts of the LCD need to be accessible as managed objects. That's where the View-based Access Control Model Configuration MIB comes in. It defines these managed object types and it's included in this document 🧚
2. Elements of the Model 💜
This section has the definitions that make the access control service of the View-based Access Control Model actually work ✨
2.1. Groups 👯
A group is a set of zero or more <securityModel, securityName> tuples that SNMP management objects can be accessed on behalf of. A group defines the access rights given to all the securityNames that belong to that group. A given combination of a securityModel and a securityName maps to at most one group. A group is identified by a groupName 🎀
The Access Control module assumes the securityName has already been authenticated (as needed), and it doesn't do any further authentication of its own. Not its job, bestie 💅
When called to check for access rights, the View-based Access Control Model uses the securityModel and the securityName as inputs to the Access Control module. It figures out the groupName as a function of securityModel and securityName 🧩
2.2. securityLevel 🔒
Members of a group can have different access rights for different levels of security, i.e., noAuthNoPriv, authNoPriv, and authPriv. This is giving "security tiers" ✨ The securityLevel tells you which level of security is assumed when checking for access rights. For the definition of securityLevel, see the SNMP Architecture document [RFC2261] 📖
The View-based Access Control Model requires that the securityLevel is passed as input to the Access Control module when it's called to check for access rights 🫶
2.3. Contexts 🗂️
An SNMP context is a collection of management information that an SNMP entity can access. An item of management information can exist in more than one context, and an SNMP entity can potentially have access to many contexts. If you want details on how management information is named, look in the SNMP Architecture document [RFC2261] 🌈
The View-based Access Control Model defines a vacmContextTable that lists the locally available contexts by contextName 💖
2.4. MIB Views and View Families 🪟
okay this is the part I'm obsessed with 😭 For security reasons, it's often super valuable to restrict the access rights of some groups to only a subset of the management information in the management domain. To make that possible, access to a context goes through a "MIB view," which details a specific set of managed object types (and optionally, the specific instances of those object types) within that context. For a given context there's typically one MIB view that gives access to all the management information in that context, and often there are other MIB views that each contain some subset of the info. So the access a group gets can be restricted just by specifying its rights in terms of the particular (subset) MIB view it can access within each appropriate context 🦋
Managed object types (and their instances) are identified by the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO-ASN.1, RFC1902]. So it's convenient to define a MIB view as a combination of a set of "view subtrees," where each view subtree is a subtree within the managed object naming tree. A simple MIB view (e.g., all managed objects within the Internet Network Management Framework) can be a single view subtree, while more complicated MIB views (e.g., all information relevant to a particular network interface) can be the union of multiple view subtrees 🍓
Any set of managed objects can be described by the union of some number of view subtrees, but sometimes you'd end up needing a very large number of them 💀 This could happen, for example, when you specify all the columns in one conceptual row of a MIB table, because they'd each show up in separate subtrees (one per column), each with a very similar format. Since the formats are similar, that 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 it conceptually represents. A family of view subtrees can either be included in or excluded from a MIB view ✨
2.4.1. View Subtree 🌳
A view subtree is the set of all MIB object instances that share a common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is identified by the OBJECT IDENTIFIER value that's 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 the family mask). The family mask shows 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 the family name does, 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.
Okay so 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 test above, its value is implicitly extended with ones. So, consequently, a view subtree family with a family mask of zero length always corresponds to a single view subtree 🧚 periodt 💅
2.5. Access Policy
okay so this is where the access rights get real 💅 The View-based Access Control Model figures out what a group is allowed to do. A group is basically a bunch of securityNames (zero or more) that all share the same access rights 🎀 For a given context (identified by contextName) that a group (identified by groupName) can reach, using a particular securityModel and securityLevel, the group's rights come down to three views: a read-view, a write-view, and a notify-view ✨
The read-view is the set of object instances the group is allowed to read. Reading happens when you process a retrieval operation, like a GetRequest, GetNextRequest, or GetBulkRequest 📖
The write-view is the set of object instances the group is allowed to write. Writing happens when you process a write operation, like a Set 🖊️
The notify-view is the set of object instances the group is allowed to send in a notification. Notifications are things like an Inform or an SNMPv2-Trap 🔔
3. Elements of Procedure
this section is the playbook 📋 It describes what an Access Control module (the one implementing the View-based Access Control Model) does when an application asks it to check access. Think a Command Responder or a Notification Originator application. The abstract service primitive looks like this:
statusInformation = -- success or errorIndication
isAccessAllowed(
securityModel -- Security Model in use
securityName -- principal who wants access
securityLevel -- Level of Security
viewType -- read, write, or notify view
contextName -- context containing variableName
variableName -- OID for the managed object
)and these are the abstract data elements, so you know exactly what each one means 🧚
statusInformation - one of the following:
accessAllowed - a MIB view was found and access is granted.
notInView - a MIB view was found but access is denied.
The variableName is not in the configured
MIB view for the specified viewType (e.g., in
the relevant entry in the vacmAccessTable).
noSuchView - no MIB view found because no view has been
configured for specified viewType (e.g., in
the relevant entry in the vacmAccessTable).
noSuchContext - no MIB view found because of no entry in the
vacmContextTable for specified contextName.
noGroupName - no MIB view found because no entry has been
configured in the vacmSecurityToGroupTable
for the specified combination of
securityModel and securityName.
noAccessEntry - no MIB view found because no entry has been
configured in the vacmAccessTable for the
specified combination of contextName,
groupName (from vacmSecurityToGroupTable),
securityModel and securityLevel.
otherError - failure, an undefined error occurred.
securityModel - Security Model under which access is requested.
securityName - the principal on whose behalf access is requested.
securityLevel - Level of Security under which access is requested.
viewType - view to be checked (read, write or notify).
contextName - context in which access is requested.
variableName - object instance to which access is requested.3.1. Overview of isAccessAllowed Process
here's the big picture 🖼️ This diagram shows how the View-based Access Control Model makes its access decision, step by step, from who, where, how, why, what, and which 🌸
+--------------------------------------------------------------------+
| |
| +-> securityModel -+ |
| | (a) | |
| who -+ +-> groupName ----+ |
| (1) | | (x) | |
| +-> securityName --+ | |
| (b) | |
| | |
| where -> contextName ---------------------+ |
| (2) (e) | |
| | |
| | |
| +-> securityModel -------------------+ |
| | (a) | |
| how -+ +-> viewName -+ |
| (3) | | (y) | |
| +-> securityLevel -------------------+ | |
| (c) | +-> yes/no |
| | | decision |
| why ---> viewType (read/write/notify) ----+ | (z) |
| (4) (d) | |
| | |
| what --> object-type ------+ | |
| (5) (m) | | |
| +-> variableName (OID) ------+ |
| | (f) |
| which -> object-instance --+ |
| (6) (n) |
| |
+--------------------------------------------------------------------+here's how the decision for isAccessAllowed actually gets made 🔍
- Inputs. The isAccessAllowed service takes these:
- (a) securityModel: the Security Model in use
- (b) securityName: the principal who wants to access
- (c) securityLevel: the Level of Security
- (d) viewType: read, write, or notify view
- (e) contextName: the context containing variableName
- (f) variableName: the OID for the managed object, made up of:
- object-type (m)
- object-instance (n)
- Who. The partial "who" (1), which is the securityModel (a) and the securityName (b), gets used as the indices (a,b) into the vacmSecurityToGroupTable. That finds a single entry that produces a group, called groupName (x) 👑
- Where and how. The "where" (2) is the contextName (e). The "who" is the groupName (x) from the last step. The "how" (3) is the securityModel (a) and securityLevel (c). Together they become the indices (e,x,a,c) into the vacmAccessTable, which finds one entry holding three MIB views 🧩
- Why. The "why" (4) is the viewType (d). It picks the right MIB view, called viewName (y), out of the vacmAccessEntry we just found. That viewName (y) is an index into the vacmViewTreeFamilyTable, and it selects the entries that say which variableNames are included in or excluded from that MIB view 🦋
- What and which. Finally, the "what" (5) type of management data and the "which" (6) particular instance, which is the variableName (f), gets checked against the MIB view. That gives the yes/no decision (z) 💖
3.2. Processing the isAccessAllowed Service Request
this section walks through what the Access Control module does every time it gets an isAccessAllowed request 🚦
- The vacmContextTable gets checked for info about the SNMP context named by contextName. If that context isn't in the table, an errorIndication (noSuchContext) goes back to the calling module 🙅♀️
- The vacmSecurityToGroupTable gets checked to map the securityModel and securityName to a groupName. If that combination isn't in the table, an errorIndication (noGroupName) goes back to the calling module 😭
- The vacmAccessTable gets checked for info about the groupName, contextName, securityModel, and securityLevel. If that combination isn't there, an errorIndication (noAccessEntry) goes back to the calling module 🥲
- Next, the right view gets picked based on viewType:
- a) If the viewType is "read", the read view is used for checking access rights.
- b) If the viewType is "write", the write view is used for checking access rights.
- c) If the viewType is "notify", the notify view is used for checking access rights.
If the view to be used is the empty view (zero length viewName), an errorIndication (noSuchView) goes back to the calling module. Not it 💀
- Last check, the actual access decision:
- a) If no view is configured for the specified viewType, an errorIndication (noSuchView) goes back to the calling module.
- b) If the specified variableName (object instance) is not in the MIB view (see the DESCRIPTION clause for vacmViewTreeFamilyTable in section 4), an errorIndication (notInView) goes back to the calling module.
Otherwise,
- c) The specified variableName is in the MIB view. A statusInformation of success (accessAllowed) goes back to the calling module. Access granted, slay ✨
4. Definitions
the part where the actual MIB module gets defined 📜 It starts like this:
SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGINokay bestie, the MIB module is about to get SO good 💅✨ here's the import list and the module header, plus the whole View-based Access Control tables we're looking at 🎀
IMPORTS
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
MODULE-IDENTITY, OBJECT-TYPE,
snmpModules FROM SNMPv2-SMI
TestAndIncr,
RowStatus, StorageType FROM SNMPv2-TC
SnmpAdminString,
SnmpSecurityLevel,
SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB;
snmpVacmMIB MODULE-IDENTITY
LAST-UPDATED "9711200000Z" -- 20 Nov 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
phone: +1-408-526-5260
"
DESCRIPTION "The management information definitions for the
View-based Access Control Model for SNMP.
"
::= { snmpModules 5 }
-- Administrative assignments ****************************************
vacmMIBObjects OBJECT IDENTIFIER ::= { snmpVacmMIB 1 }
vacmMIBConformance OBJECT IDENTIFIER ::= { snmpVacmMIB 2 }
-- Information about Local Contexts **********************************
vacmContextTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmContextEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of locally available contexts.
This table provides information to SNMP Command
Generator applications so that they can properly
configure the vacmAccessTable to control access to
all contexts at the SNMP entity.
This table may change dynamically if the SNMP entity
allows that contexts are added/deleted dynamically
(for instance when its configuration changes). Such
changes would happen only if the management
instrumentation at that SNMP entity recognizes more
(or fewer) contexts.
The presence of entries in this table and of entries
in the vacmAccessTable are independent. That is, a
context identified by an entry in this table is not
necessarily referenced by any entries in the
vacmAccessTable; and the context(s) referenced by an
entry in the vacmAccessTable does not necessarily
currently exist and thus need not be identified by an
entry in this table.
This table must be made accessible via the default
context so that Command Responder applications have
a standard way of retrieving the information.
This table is read-only. It cannot be configured via
SNMP.
"
::= { vacmMIBObjects 1 }
vacmContextEntry OBJECT-TYPE
SYNTAX VacmContextEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information about a particular context."
INDEX {
vacmContextName
}
::= { vacmContextTable 1 }
VacmContextEntry ::= SEQUENCE
{
vacmContextName SnmpAdminString
}
vacmContextName 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.
The empty contextName (zero length) represents the
default context.
"
::= { vacmContextEntry 1 }
-- Information about Groups ******************************************
vacmSecurityToGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmSecurityToGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table maps a combination of securityModel and
securityName into a groupName which is used to define
an access control policy for a group of principals.
"
::= { vacmMIBObjects 2 }
vacmSecurityToGroupEntry OBJECT-TYPE
SYNTAX VacmSecurityToGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in this table maps the combination of a
securityModel and securityName into a groupName.
"
INDEX {
vacmSecurityModel,
vacmSecurityName
}
::= { vacmSecurityToGroupTable 1 }
VacmSecurityToGroupEntry ::= SEQUENCE
{
vacmSecurityModel SnmpSecurityModel,
vacmSecurityName SnmpAdminString,
vacmGroupName SnmpAdminString,
vacmSecurityToGroupStorageType StorageType,
vacmSecurityToGroupStatus RowStatus
}
vacmSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel(1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The Security Model, by which the vacmSecurityName
referenced by this entry is provided.
Note, this object may not take the 'any' (0) value.
"
::= { vacmSecurityToGroupEntry 1 }
vacmSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The securityName for the principal, represented in a
Security Model independent format, which is mapped by
this entry to a groupName.
The securityName for a principal represented in a
Security Model independent format.
"
::= { vacmSecurityToGroupEntry 2 }
vacmGroupName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
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 is used as index into the
vacmAccessTable to select an access control policy.
"
::= { vacmSecurityToGroupEntry 3 }
vacmSecurityToGroupStorageType 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 }
::= { vacmSecurityToGroupEntry 4 }
vacmSecurityToGroupStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The RowStatus TC [RFC1903] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { vacmSecurityToGroupEntry 5 }
-- Information about Access Rights ***********************************
vacmAccessTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of access rights for groups.
Each entry is indexed by a contextPrefix, a groupName
a securityModel and a securityLevel. 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, follow these steps:
1) the set of possible matches is formed by the
intersection of the following sets of entries:
the set of entries with identical vacmGroupName
the union of these two sets:
- the set with identical vacmAccessContextPrefix
- the set of entries with vacmAccessContextMatch
value of 'prefix' and matching
vacmAccessContextPrefix
intersected with the union of these two sets:
- the set of entries with identical
vacmSecurityModel
- the set of entries with vacmSecurityModel
value of 'any'
intersected with the set of entries with
vacmAccessSecurityLevel value less than or equal
to the requested securityLevel
2) if this set has only one member, we're done
otherwise, it comes down to deciding how to weight
the preferences between ContextPrefixes,
SecurityModels, and SecurityLevels as follows:
a) if the subset of entries with identical
securityModels is not empty, discard the rest.
b) if the subset of entries with identical
vacmAccessContextPrefix is not empty,
discard the rest
c) discard all entries with ContextPrefixes shorter
than the longest one remaining in the set
d) select the entry with the highest securityLevel
Please note that for securityLevel noAuthNoPriv, all
groups are really equivalent since the assumption that
the securityName has been authenticated does not hold.
"
::= { vacmMIBObjects 4 }
vacmAccessEntry OBJECT-TYPE
SYNTAX VacmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An access right configured in the Local Configuration
Datastore (LCD) authorizing access to an SNMP context.
"
INDEX { vacmGroupName,
vacmAccessContextPrefix,
vacmAccessSecurityModel,
vacmAccessSecurityLevel
}
::= { vacmAccessTable 1 }the vacmAccessTable selection steps are basically a bouncer checklist 🙈 match the group, match the context, match the security model, match the level, then break ties in order. iykyk 💀
the context table is the guest list for the default context, and the access table is who gets past the velvet rope 🧚💜
okay bestie, we're deep in the access rules now 🔐✨ this first block is the shape of one access row, and it's giving very organized energy 💅
VacmAccessEntry ::= SEQUENCE
{
vacmAccessContextPrefix SnmpAdminString,
vacmAccessSecurityModel SnmpSecurityModel,
vacmAccessSecurityLevel SnmpSecurityLevel,
vacmAccessContextMatch INTEGER,
vacmAccessReadViewName SnmpAdminString,
vacmAccessWriteViewName SnmpAdminString,
vacmAccessNotifyViewName SnmpAdminString,
vacmAccessStorageType StorageType,
vacmAccessStatus RowStatus
}
vacmAccessContextPrefix OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
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 vacmAccessContextMatch is 'exact')
or partially (if the value of vacmAccessContextMatch
is 'prefix') to the value of the instance of this
object.
"
::= { vacmAccessEntry 1 }
vacmAccessSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "In order to gain the access rights allowed by this
conceptual row, this securityModel must be in use.
"
::= { vacmAccessEntry 2 }
vacmAccessSecurityLevel OBJECT-TYPE
SYNTAX SnmpSecurityLevel
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. A securityLevel of noAuthNoPriv is less than
authNoPriv which in turn is less than authPriv.
If multiple entries are equally indexed except for
this vacmAccessSecurityLevel index, then the entry
which has the highest value for
vacmAccessSecurityLevel wins.
"
::= { vacmAccessEntry 3 }
vacmAccessContextMatch 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 the value of this object is exact(1), then all
rows where the contextName exactly matches
vacmAccessContextPrefix are selected.
If the value of this object is prefix(2), then all
rows where the contextName whose starting octets
exactly match vacmAccessContextPrefix are selected.
This allows for a simple form of wildcarding.
See also the example in the DESCRIPTION clause of
the vacmAccessTable above.
"
::= { vacmAccessEntry 4 }
vacmAccessReadViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
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
vacmViewTreeFamilyViewName 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 vacmViewTreeFamilyViewName, then no access
is granted.
"
DEFVAL { ''H } -- the empty string
::= { vacmAccessEntry 5 }
vacmAccessWriteViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
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
vacmViewTreeFamilyViewName 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 vacmViewTreeFamilyViewName, then no access
is granted.
"
DEFVAL { ''H } -- the empty string
::= { vacmAccessEntry 6 }
vacmAccessNotifyViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
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
vacmViewTreeFamilyViewName 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 vacmViewTreeFamilyViewName, then no access
is granted.
"
DEFVAL { ''H } -- the empty string
::= { vacmAccessEntry 7 }
vacmAccessStorageType 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 }
::= { vacmAccessEntry 8 }
vacmAccessStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The RowStatus TC [RFC1903] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { vacmAccessEntry 9 }okay now we're moving on to MIB views 🦋 this part is all about which slices of the MIB a row can actually see, and the comments here are lowkey important 👀
-- Information about MIB views ***************************************
-- Support for instance-level granularity is optional.
--
-- In some implementations, instance-level access control
-- granularity may come at a high performance cost. Managers
-- should avoid requesting such configurations unnecessarily.
vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }
vacmViewSpinLock 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 or modifying
views.
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
vacmViewSpinLock 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 vacmViewTreeFamilyTable. 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.
"
::= { vacmMIBViews 1 }
vacmViewTreeFamilyTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Locally held information about families of subtrees
within MIB views.
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 the included and the
excluded ones, 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 vacmViewTreeFamilyType in the entry whose
value of vacmViewTreeFamilySubtree has the most
sub-identifiers. If multiple entries match and have
the same number of sub-identifiers, then the
lexicographically greatest instance of
vacmViewTreeFamilyType 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 vacmViewTreeFamilySubtree for the entry,
and each sub-identifier in the value of
vacmViewTreeFamilySubtree matches its corresponding
sub-identifier in X. Two sub-identifiers match
either if the corresponding bit of the value of
vacmViewTreeFamilyMask 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
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask.
In the case where no 'wild card' is defined in the
vacmViewTreeFamilyMask, the family of subtrees reduces
to a single subtree.
When creating or changing MIB views, an SNMP Command
Generator application should utilize the
vacmViewSpinLock to try to avoid collisions. See
DESCRIPTION clause of vacmViewSpinLock.
When creating MIB views, it is strongly advised that
first the 'excluded' vacmViewTreeFamilyEntries are
created and then the 'included' entries.
When deleting MIB views, it is strongly advised that
first the 'included' vacmViewTreeFamilyEntries are
deleted and then the 'excluded' entries.
If a create for an entry for instance-level access
control is received and the implementation does not
support instance-level granularity, then an
inconsistentName error must be returned.
"
::= { vacmMIBViews 2 }Okay so we're picking up right where the table left off, and the vacmViewTreeFamilyEntry is literally the main character 🦋✨
vacmViewTreeFamilyEntry OBJECT-TYPE
SYNTAX VacmViewTreeFamilyEntry
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
vacmViewTreeFamilyTable.
If no conceptual rows exist in this table for a given
MIB view (viewName), that view may be thought of as
consisting of the empty set of view subtrees.
"
INDEX { vacmViewTreeFamilyViewName,
vacmViewTreeFamilySubtree
}
::= { vacmViewTreeFamilyTable 1 }
VacmViewTreeFamilyEntry ::= SEQUENCE
{
vacmViewTreeFamilyViewName SnmpAdminString,
vacmViewTreeFamilySubtree OBJECT IDENTIFIER,
vacmViewTreeFamilyMask OCTET STRING,
vacmViewTreeFamilyType INTEGER,
vacmViewTreeFamilyStorageType StorageType,
vacmViewTreeFamilyStatus RowStatus
}Basically, a family of view subtrees is a group of MIB subtrees that's either in or out of a view 🌸 The DESCRIPTION says there's no cap on how many families you can have for one view, apart from resource limits on the whole table. And if a view has zero rows in this table, it's giving empty set 🫠
vacmViewTreeFamilyViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The human readable name for a family of view subtrees.
"
::= { vacmViewTreeFamilyEntry 1 }
vacmViewTreeFamilySubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The MIB subtree which when combined with the
corresponding instance of vacmViewTreeFamilyMask
defines a family of view subtrees.
"
::= { vacmViewTreeFamilyEntry 2 }The name is the readable label for the family, and the subtree is the OID root that the mask gets applied to. Cute pairing, honestly 🎀
vacmViewTreeFamilyMask 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 vacmViewTreeFamilySubtree,
defines a family of view subtrees.
Each bit of this bit mask corresponds to a
sub-identifier of vacmViewTreeFamilySubtree, 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
vacmViewTreeFamilySubtree, either:
the i-th bit of vacmViewTreeFamilyMask is 0, or
the i-th sub-identifier of X is equal to the i-th
sub-identifier of the value of
vacmViewTreeFamilySubtree.
If the value of this bit mask is M bits long and
there are more than M sub-identifiers in the
corresponding instance of vacmViewTreeFamilySubtree,
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 vacmViewTreeFamilySubtree.
Note that masks of length greater than zero length
do not need to be supported. In this case this
object is made read-only.
"
DEFVAL { ''H }
::= { vacmViewTreeFamilyEntry 3 }Okay, the mask is where it gets extra 🤓 Each bit lines up with one sub-identifier. A 1 means that sub-identifier has to match exactly, and a 0 is a wild card that matches anything. If the mask runs out before the subtree does, the rest gets padded with 1s, so you get exact matching. And an empty mask (zero-length) means all 1s, so it's one exact subtree and no wild cards. Also, supporting masks longer than zero length is optional, and if you skip it, this object goes read-only 🙈
vacmViewTreeFamilyType OBJECT-TYPE
SYNTAX INTEGER { included(1), excluded(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Indicates whether the corresponding instances of
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask
define a family of view subtrees which is included in
or excluded from the MIB view.
"
DEFVAL { included }
::= { vacmViewTreeFamilyEntry 4 }
vacmViewTreeFamilyStorageType 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 }
::= { vacmViewTreeFamilyEntry 5 }
vacmViewTreeFamilyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
The RowStatus TC [RFC1903] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { vacmViewTreeFamilyEntry 6 }So the type decides whether the family is included or excluded from the view ✨ Storage type defaults to nonVolatile, and 'permanent' rows don't need to allow writes to their columns. The status one is a little plot twist 🙃 It says the RowStatus value doesn't change whether the other columns in the row can be edited.
-- Conformance information *******************************************
vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }
-- Compliance statements *********************************************
vacmMIBCompliance 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 { vacmBasicGroup }
OBJECT vacmAccessContextMatch
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessReadViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessWriteViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessNotifyViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessStatus
MIN-ACCESS read-only
DESCRIPTION "Create/delete/modify access to the
vacmAccessTable is not required.
"
OBJECT vacmViewTreeFamilyMask
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 vacmViewTreeFamilyType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmViewTreeFamilyStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmViewTreeFamilyStatus
MIN-ACCESS read-only
DESCRIPTION "Create/delete/modify access to the
vacmViewTreeFamilyTable is not required.
"
::= { vacmMIBCompliances 1 }Now the compliance bit, which is basically the "you don't have to do all of this" section 🫶 Most of these objects are read-only, and the mask only needs to accept a zero-length value for writes. You can skip the wild-card config over SNMP totally. That's valid, periodt 💅
-- Units of conformance **********************************************
vacmBasicGroup OBJECT-GROUP
OBJECTS {
vacmContextName,
vacmGroupName,
vacmSecurityToGroupStorageType,
vacmSecurityToGroupStatus,
vacmAccessContextMatch,
vacmAccessReadViewName,
vacmAccessWriteViewName,
vacmAccessNotifyViewName,
vacmAccessStorageType,
vacmAccessStatus,
vacmViewSpinLock,
vacmViewTreeFamilyMask,
vacmViewTreeFamilyType,
vacmViewTreeFamilyStorageType,
vacmViewTreeFamilyStatus
}
STATUS current
DESCRIPTION "A collection of objects providing for remote
configuration of an SNMP engine which implements
the SNMP View-based Access Control Model.
"
::= { vacmMIBGroups 1 }
ENDThe basic group is the whole bundle of objects you need for remote config of a View-based Access Control Model engine 👑 Everything lives in one tidy group, so the vibes are immaculate 🌈
5. Intellectual Property ✨
Okay, legal bit, but it's actually chill 🧚 The IETF doesn't take a stance on whether any intellectual property or other rights that might be claimed around this technology are valid or how far they reach, and it doesn't claim it's looked for any of them either. If you want the details on how the IETF handles rights for standards-track and standards-related docs, check out BCP-11. Copies of rights claims, promised licenses, or results from trying to get a general license or permission for implementers or users can be requested from the IETF Secretariat 📬
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard. Send that info to the IETF Executive Director 💌
6. Acknowledgements 🫶✨
Okay bestie, this is the shoutout section, and it is SO deserved 💖 This document is the result of the efforts of the SNMPv3 Working Group. Special thanks go to these SNMPv3 WG members:
- Dave Battle (SNMP Research, Inc.)
- Uri Blumenthal (IBM T.J. Watson Research Center)
- Jeff Case (SNMP Research, Inc.)
- John Curran (BBN)
- T. Max Devlin (Hi-TECH Connections)
- John Flick (Hewlett Packard)
- David Harrington (Cabletron Systems Inc.)
- N.C. Hien (IBM T.J. Watson Research Center)
- Dave Levi (SNMP Research, Inc.)
- Louis A Mamakos (UUNET Technologies Inc.)
- Paul Meyer (Secure Computing Corporation)
- Keith McCloghrie (Cisco Systems)
- Russ Mundy (Trusted Information Systems, Inc.)
- Bob Natale (ACE*COMM Corporation)
- Mike O'Dell (UUNET Technologies Inc.)
- Dave Perkins (DeskTalk)
- Peter Polkinghorne (Brunel University)
- Randy Presuhn (BMC Software, Inc.)
- David Reid (SNMP Research, Inc.)
- Shawn Routhier (Epilogue)
- Juergen Schoenwaelder (TU Braunschweig)
- Bob Stewart (Cisco Systems)
- Bert Wijnen (IBM T.J. Watson Research Center)
The document is also based on recommendations from the IETF Security and Administrative Framework Evolution for SNMP Advisory Team 🌸 The members of that Advisory Team were:
- David Harrington (Cabletron Systems Inc.)
- Jeff Johnson (Cisco Systems)
- 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 Center)
As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design pulls in as much as is practical from previous RFCs and drafts. So special thanks are also due to the authors of the earlier designs known as SNMPv2u and SNMPv2* 🍓:
- Jeff Case (SNMP Research, Inc.)
- David Harrington (Cabletron Systems Inc.)
- David Levi (SNMP Research, Inc.)
- Keith McCloghrie (Cisco Systems)
- Brian O'Keefe (Hewlett Packard)
- Marshall T. Rose (Dover Beach Consulting)
- Jon Saperia (BGS Systems Inc.)
- Steve Waldbusser (International Network Services)
- Glenn W. Waters (Bell-Northern Research Ltd.)
7. Security Considerations 🚨💀
Real talk, this section is serious, so read it carefully 🔥
7.1. Recommended Practices
This document is meant for use in the SNMP architecture. The View-based Access Control Model described here checks access rights to management information based on:
contextName, which represents a set of management information at the managed system where the Access Control module is running.groupName, which represents a set of zero or more securityNames. The combination of a securityModel and a securityName is mapped into a group in the View-based Access Control Model.securityModelunder which access is requested.securityLevelunder which access is requested.- The operation performed on the management information.
- MIB views for read, write or notify access.
When the User-based Access Control module is called to check access rights, it is assumed that the calling module has already ensured the authentication and privacy aspects specified by the securityLevel being passed in. Trust the process, bestie 🦋
When creating or deleting entries in the vacmViewFamiliyTreeTable, it is important to do it in the sequence recommended in the DESCRIPTION clause of the vacmViewFamilityTable definition. Otherwise, unwanted access may be granted while the entries in the table are changing.
⚠️ Yes, the order matters. Do NOT freestyle the sequence or you could accidentally hand out access you never meant to give. Main character energy is NOT the same as chaos 😭
7.2. Defining Groups
The groupNames are used to give access to a group of zero or more securityNames. Within the View-Based Access Control Model, a groupName is considered to exist if that groupName is listed in the vacmSecurityToGroupTable 🧚
By mapping the combination of a securityModel and securityName into a groupName, an SNMP Command Generator application can add or delete securityNames to and from a group, as long as proper access is allowed.
It's also important to realize that the grouping of <securityModel, securityName> tuples in the vacmSecurityToGroupTable does NOT take securityLevel into account 🙈 That means the security administrator really needs to use the securityLevel index in the vacmAccessTable to separate noAuthNoPriv from authPriv and/or authNoPriv access. Don't skip this one, it's giving "oops, my bad" energy if you do 💅
7.3. Conformance
For an implementation of the View-based Access Control Model to count as conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB. It also SHOULD implement the initial configuration described in Appendix A 🎀
8. References 📚
- [RFC1902] Case, J., McCloghrie, K., Rose, M. and S., Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
- [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2261] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for describing SNMP Management Frameworks", RFC 2261, January 1998.
- [RFC2262] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2262, January 1998.
- [RFC2264] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2264, January 1998.
- [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).
9. Editors' Addresses 💌
These are the people to contact, bestie 🌈
Bert Wijnen
IBM T. J. Watson Research
Schagen 33
3461 GL Linschoten
Netherlands
EMail: wijnen@vnet.ibm.com
Phone: +31-348-432-794
Randy Presuhn
BMC Software, Inc
1190 Saratoga Avenue, Suite 130
San Jose, CA 95129-3433
USA
EMail: rpresuhn@bmc.com
Phone: +1-408-556-0720
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
EMail: kzm@cisco.com
Phone: +1-408-526-5260APPENDIX A - Installation ⚙️🎀
A.1. Installation Parameters
During installation, an authoritative SNMP engine that supports this View-based Access Control Model SHOULD be configured with several initial parameters. These include, for the View-based Access Control Model, the following:
1) A security configuration
The choice of security configuration determines whether an initial configuration is implemented and, if so, how. One of three possible choices is selected:
initial-minimum-security-configurationinitial-semi-security-configurationinitial-no-access-configuration
In the case of a initial-no-access-configuration, there is no initial configuration, so the following steps are irrelevant 🙃
2) A default context
One entry in the vacmContextTable 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
------------------ ---------------
vacmContextName "" ""3) An initial group
One entry in the vacmSecurityToGroupTable to allow access to group "initial" 🍓
no privacy support privacy support
------------------ ---------------
vacmSecurityModel 3 (USM) 3 (USM)
vacmSecurityName "initial" "initial"
vacmGroupName "initial" "initial"
vacmSecurityToGroupStorageType anyValidStorageType anyValidStorageType
vacmSecurityToGroupStatus active active4) Initial access rights
Three entries in the vacmAccessTable are needed, as follows:
- Read-notify access for securityModel USM, securityLevel "noAuthNoPriv", on behalf of securityNames that belong to the group "initial", to the <restricted> MIB view in the default context with contextName "".
- Read-write-notify access for securityModel USM, securityLevel "authNoPriv", on behalf of securityNames that belong to the group "initial", to the <internet> MIB view in the default context with contextName "".
- If privacy is supported, read-write-notify access for securityModel USM, securityLevel "authPriv", on behalf of securityNames that belong to the group "initial", to the <internet> MIB view in the default context with contextName "".
That translates into the following entries in the vacmAccessTable. Columns marked with (index) are index-only objects and are not really present in this table 💜
- One entry to be used for unauthenticated access (noAuthNoPriv):
no privacy support privacy support
------------------ ---------------
vacmAccessContextPrefix "" ""
vacmGroupName (index) "initial" "initial"
vacmSecurityModel (index) 3 (USM) 3 (USM)
vacmAccessSecurityLevel noAuthNoPriv noAuthNoPriv
vacmAccessReadViewName "restricted" "restricted"
vacmAccessWriteViewName "" ""
vacmAccessNotifyViewName "restricted" "restricted"
vacmAccessStorageType anyValidStorageType anyValidStorageType
vacmAccessStatus active active- One entry to be used for authenticated access but without privacy (authNoPriv):
no privacy support privacy support
------------------ ---------------
vacmAccessContextPrefix "" ""
vacmGroupName (index) "initial" "initial"
vacmSecurityModel (index) 3 (USM) 3 (USM)
vacmAccessSecurityLevel authNoPriv authNoPriv
vacmAccessReadViewName "internet" "internet"
vacmAccessWriteViewName "internet" "internet"
vacmAccessNotifyViewName "internet" "internet"
vacmAccessStorageType anyValidStorageType anyValidStorageType
vacmAccessStatus active active- One entry to be used for authenticated access with privacy (authPriv):
no privacy support privacy support
------------------ ---------------
vacmAccessContextPrefix ""
vacmGroupName (index) "initial"
vacmSecurityModel (index) 3 (USM)
vacmAccessSecurityLevel authPriv
vacmAccessReadViewName "internet"
vacmAccessWriteViewName "internet"
vacmAccessNotifyViewName "internet"
vacmAccessStorageType anyValidStorageType
vacmAccessStatus active- Two MIB views, of which the second one depends on the security configuration. okay so this one is a lil bit of a plot twist 👀🎀
- One view, the
<internet>view, for authenticated access:- the
<internet>MIB view is the following subtree:"internet" (subtree 1.3.6.1)
- the
- A second view, the
<restricted>view, for unauthenticated access. This view is configured according to the selected security configuration:- For the initial-no-access-configuration there is no default initial configuration, so no MIB views are pre-scribed. 🙅♀️ nothing gets set up here, bestie.
- For the initial-semi-secure-configuration, the
<restricted>MIB view is the union of these subtrees: - For the initial-minimum-secure-configuration, the
<restricted>MIB view is the following subtree:"internet" (subtree 1.3.6.1)🔒✨
This translates into the following "internet" entry in the vacmViewTreeFamilyTable, and it's giving clean and simple 💅
minimum-secure semi-secure
---------------- ---------------
vacmViewTreeFamilyViewName "internet" "internet"
vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1
vacmViewTreeFamilyMask "" ""
vacmViewTreeFamilyType 1 (included) 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
vacmViewTreeFamilyStatus active activeIn addition it translates into the following "restricted" entries in the vacmViewTreeFamilyTable. this part is lowkey a lot, but every row matters 🦋
minimum-secure semi-secure
---------------- ---------------
vacmViewTreeFamilyViewName "restricted" "restricted"
vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1
vacmViewTreeFamilyMask "" ""
vacmViewTreeFamilyType 1 (included) 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
vacmViewTreeFamilyStatus active active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.2.1.11
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.7.2.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.8.2.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName "restricted"
vacmViewTreeFamilySubtree 1.3.6.1.6.3.9.2.1
vacmViewTreeFamilyMask ""
vacmViewTreeFamilyType 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType
vacmViewTreeFamilyStatus activeB. Full Copyright Statement ⚖️💖
Okay, last bit, and I'm keeping the legal text word for word so nobody gets into trouble 🫶
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
That's the whole thing, bestie 🌈👑 we made it through all 7 parts!
📦 where this page comes from
- ietf: rfc2265 1998-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms