In SNMPv3, what does the User-based Security Model check on each message, and what does the View-based Access Control Model decide afterwards?
answer
- two subsystems, two questions
- who sent it, and is it intact
- timely, and was it encrypted
- group, context, level, then view
- read, write and notify views
basics
~20 sThe User-based Security Model (RFC 3414) establishes which user sent an SNMPv3 message and protects it with authentication, a replay window and optional encryption. The View-based Access Control Model (RFC 3415) then decides which objects that user may read, write or receive.
solid answer
~40 sSNMPv3 splits security in two. The **User-based Security Model** (`USM`, RFC 3414) works on the *message*: it looks up the user named in `msgUserName`, verifies the HMAC over the whole message with that user's key, checks `snmpEngineBoots` and `snmpEngineTime` against a 150-second window, and decrypts the `scopedPDU` if privacy was used. It hands on a `securityName` and the `securityLevel` the message achieved. The **View-based Access Control Model** (`VACM`, RFC 3415) then works on the *request*: it maps security model plus name to a group, picks an access row by context, model and level, and checks every object against that row's read, write or notify view. USM answers *who sent this and was it tampered with*; VACM answers *what may they touch*. VACM performs no authentication of its own.
go deeper
Recall the two names and their one-line jobs: USM authenticates and encrypts the message, VACM decides which objects the authenticated user may touch.
Walk the order USM checks a message in - engine ID, user, level, HMAC, time window, decryption - and the four VACM tables a request passes through.
Show you can tell the failures apart in production: usmStats counters and Reports point at USM, while authorizationError, noSuchObject or noAccess point at VACM configuration.
Discuss why separating identity from authorisation lets you rotate keys and reshape views independently, and when a transport security model is worth adopting instead of USM.
## Why SNMPv3 has two security subsystems Community-based SNMP folded identity and permission into one shared string. SNMPv3 (the RFC 3411-3418 set) separates them into two pluggable subsystems inside every SNMP engine: - the **Security Subsystem**, whose standard model is the **User-based Security Model** (`USM`, RFC 3414), protects the *message*; - the **Access Control Subsystem**, whose standard model is the **View-based Access Control Model** (`VACM`, RFC 3415), authorises the *operation* inside it. RFC 3415 is explicit about the boundary: the access control module "assumes that the securityName has already been authenticated as needed and provides no further authentication of its own". Each subsystem trusts the other to do its half. ## What USM does to an incoming message USM reads the `msgSecurityParameters` field of the message - the authoritative engine's ID, its boots and time values, the user name, and the authentication and privacy parameters. RFC 3414 section 3.2 processes them in a fixed order: 1. **Engine ID** - is `msgAuthoritativeEngineID` known? If not, the `usmStatsUnknownEngineIDs` counter is incremented (this is also how discovery works). 2. **User** - is there a `usmUserTable` entry for this user at that engine? If not, `usmStatsUnknownUserNames`. 3. **Level** - does that user support the requested security level? If not, `usmStatsUnsupportedSecLevels`. 4. **Authentication** - the HMAC over the whole message is recomputed with the user's localized key; a mismatch counts in `usmStatsWrongDigests`. 5. **Timeliness** - only for authenticated messages: the boots and time values must fall inside the 150-second window, or `usmStatsNotInTimeWindows` is incremented. 6. **Decryption** - only if the privacy flag is set: the `encryptedPDU` is decrypted back into the `scopedPDU`. The order matters: the time values are trusted only because the HMAC that covers them has already verified, and nothing is decrypted until the message is known to be authentic and recent. What USM passes on is not a key and not a password. It is a **securityModel** (USM is model 3), a **securityName** and the **securityLevel** actually achieved - `noAuthNoPriv`, `authNoPriv` or `authPriv`. ## What VACM decides VACM is asked one question per variable: *is this access allowed?* RFC 3415 section 3.2 answers it with four tables: 1. **Context** - is the requested `contextName` in `vacmContextTable`? A context is a named collection of management information the agent exposes. 2. **Group** - `vacmSecurityToGroupTable` maps the `<securityModel, securityName>` pair to one `groupName`. Users never get rights directly. 3. **Access row** - `vacmAccessTable` is searched by group, context, security model and a *minimum* security level; the chosen row names three views. 4. **View** - the request type picks the read, write or notify view, and `vacmViewTreeFamilyTable` says whether the object identifier falls inside it. Each failure has its own name: `noSuchContext`, `noGroupName`, `noAccessEntry`, `noSuchView`, `notInView`. ## How the two connect | | USM (RFC 3414) | VACM (RFC 3415) | |---|---|---| | Works on | the whole message | each variable binding | | Question | who sent it, intact and recent, readable? | may this group touch this object? | | Keyed by | engine ID and user name | group, context, model, level | | Failure evidence | `usmStats*` counters, Report PDUs | `authorizationError`, `noSuchObject`, `noAccess` | | Holds secrets | yes - localized keys | no | The security level travels from one to the other, which is why an access row can demand `authPriv`: VACM cannot verify anything itself, but it can refuse to grant rights to a message that USM did not protect strongly enough. USM is not the only possible feeder. RFC 5591 defines the **Transport Security Model** (security model 4), which takes identity from a secure transport such as RFC 6353's TLS or DTLS transport model; VACM consumes its securityName and level exactly as it consumes USM's. ## Mistakes this split explains - **"The user authenticated, so it can read everything."** Authentication only gets a request as far as VACM; a user with no group gets `authorizationError`. - **"VACM hides objects by encrypting them."** Encryption is USM's privacy service and applies to the whole `scopedPDU`; VACM hides objects by answering as if they were absent. - **"Our access rules are per user."** They are per group; two users in one group share every right. - **"A wrong password is an access-control problem."** It never reaches VACM: USM rejects it at the HMAC check and counts it in `usmStatsWrongDigests`. Keeping the two apart is also what makes v3 operable: you rotate a user's key in USM without touching a single view, and you narrow a group's view without re-keying anyone.
- If an SNMPv3 user authenticates correctly but has no VACM group, what does its GetRequest receive?Per RFC 3413, the access check returns `noGroupName`; the command responder halts the operation and returns a Response whose error-status is `authorizationError` with error-index 0. The message passed USM, so this is an access-control refusal, not an authentication failure, and it shows up in VACM configuration rather than in the `usmStats` counters.
- Can VACM work with a security model other than USM?Yes. VACM's inputs are just a securityModel, securityName and securityLevel plus the context, view type and object. RFC 5591's Transport Security Model (model 4) supplies them from a secure transport such as RFC 6353's TLS or DTLS transport model, and the same groups, access rows and views apply.
saying these in an interview costs you the question
- USM decides which OIDs a user is allowed to read.
- VACM hides restricted objects by encrypting them.
- Any user that authenticates can read the whole MIB.
- VACM re-checks the user's credentials before granting access.
- SNMPv3 access rights are attached directly to each user.