skip to content

SNMPv3 Security Model

3 roadmaps5 questions

The user-based security model adds per-user authentication and encryption, with an engine ID and time window against replay, while VACM limits which objects each user can touch.

on this pageshow

explore

questions

5

What do SNMPv3's three security levels - noAuthNoPriv, authNoPriv and authPriv - each protect, and why is there no privacy-only level?

level: middleimportance: must knowfreq 40%

answer

  1. two bits in msgFlags
  2. authFlag and privFlag
  3. time window needs authentication
  4. HMAC first, then DES or AES
  5. the user name still shows

basics

~20 s

noAuthNoPriv names a user but proves nothing; authNoPriv adds an HMAC proving the user, integrity and freshness; authPriv also encrypts the scoped PDU. RFC 3412 forbids privacy without authentication: unauthenticated ciphertext could be altered or replayed undetected.

solid answer

~50 s

The level travels as two bits in `msgFlags` (RFC 3412), and the receiver must process the message at that level. **noAuthNoPriv** carries only `msgUserName`: no integrity, no replay check, no confidentiality - discovery uses it. **authNoPriv** adds an HMAC over the whole message with the user's localized key (HMAC-MD5-96 or HMAC-SHA-96 from RFC 3414, or the HMAC-SHA-2 set from RFC 7860), proving which user sent it, that it was not modified, and - because the time values are now trustworthy - that it is inside the 150-second window. **authPriv** also encrypts the `scopedPDU` with CBC-DES (RFC 3414) or CFB128-AES-128 (RFC 3826). If `privFlag` is set, `authFlag` must be too. A NOC user who can Set belongs at `authPriv` with HMAC-SHA-2 and AES; even then the user name and engine ID cross the wire in clear.

go deeper

for a junior

Recall the three names in order and what each adds: nothing, then authentication, then authentication plus encryption.

for a middle

Explain the authFlag and privFlag bits, why the time window needs authentication, and which RFC defines each HMAC and cipher option.

for a senior

Show the operating choices: require authPriv in the access row for writers, pick HMAC-SHA-2 and AES, use separate secrets, and know what stays visible on the wire.

for a principal

Weigh retiring MD5 and DES across a mixed estate against the gear that supports only them, and decide whether privacy is mandatory for read-only telemetry.

## Where the level is carried Every SNMPv3 message has a one-octet `msgFlags` field (RFC 3412 section 6.4). Its low bits are the **authFlag** and the **privFlag**; a third, the **reportableFlag**, says whether a Report may be sent back. The sender sets the two security bits to the level it applied, and the receiver "MUST apply the same securityLevel" when it processes the message. RFC 3411 orders the three levels: `noAuthNoPriv` < `authNoPriv` < `authPriv`. ## The three levels compared | Level | authFlag | privFlag | Origin and integrity | Replay window | Confidentiality | Typical use | |---|---|---|---|---|---|---| | `noAuthNoPriv` | 0 | 0 | none - the user name is a claim | not checked | none | engine ID discovery | | `authNoPriv` | 1 | 0 | HMAC over the whole message | checked | none | read-only polling where the data is not sensitive | | `authPriv` | 1 | 1 | HMAC over the whole message | checked | `scopedPDU` encrypted | anything that writes, or reads sensitive objects | - **noAuthNoPriv** proves nothing. The agent knows which user the sender *claims* to be and nothing else. RFC 3414 section 4 uses exactly this level for the first discovery request, which carries an empty user name and an empty engine ID. - **authNoPriv** appends a truncated HMAC computed over the entire serialised message with the user's localized authentication key. That gives **data origin authentication** (it really was this user) and **data integrity** (no byte changed). It also switches on the **timeliness check**: RFC 3414 section 1.4.1 runs the time window only on authenticated messages, because only then are the boots and time values covered by the HMAC. - **authPriv** additionally encrypts the `scopedPDU` - the context engine ID, the context name and the PDU with its variable bindings - with the user's localized privacy key. ## Why privacy never travels alone RFC 3412 states it as an architectural requirement: "if the privFlag is set, then the authFlag MUST also be set to one". RFC 3414 explains the dependency: it provides "no provision for data confidentiality without both data integrity and data origin authentication". Without the HMAC, an encrypted message could be altered or replayed and the receiver would decrypt whatever arrived, and the replay window - which depends on authenticated time values - would not apply at all. Encryption hides content; only authentication makes the content trustworthy. ## The protocols behind each level Authentication protocols for USM: - **HMAC-MD5-96** and **HMAC-SHA-96** (RFC 3414) - HMAC over MD5 or SHA-1, truncated to 12 octets in the message. RFC 3414 makes MD5 the one that MUST be supported and SHA the one that SHOULD be. - **The HMAC-SHA-2 set** (RFC 7860, which obsoletes RFC 7630): `usmHMAC128SHA224AuthProtocol`, `usmHMAC192SHA256AuthProtocol`, `usmHMAC256SHA384AuthProtocol` and `usmHMAC384SHA512AuthProtocol`, truncated to 16, 24, 32 and 48 octets. A conforming implementation MUST support the SHA-256 variant and SHOULD support the SHA-512 one. Privacy protocols for USM: - **CBC-DES** (RFC 3414) - only 56 bits of the key are used, which is far below what is considered adequate today. - **CFB128-AES-128** (RFC 3826) - AES with a 128-bit key in cipher feedback mode; its IV is built from the authoritative engine's boots and time values plus a 64-bit local value sent as the salt in `msgPrivacyParameters`. - AES-192 and AES-256 for USM are offered by some implementations but have no RFC, so interoperability depends on each implementation. The "96" in HMAC-SHA-96 is the length of the truncated MAC, not of the key: RFC 3414's MD5 and SHA keys are 16 and 20 octets. ## What authPriv still reveals Encryption covers the `scopedPDU` only. The `msgSecurityParameters` stay readable on the wire: `msgAuthoritativeEngineID`, `msgAuthoritativeEngineBoots`, `msgAuthoritativeEngineTime` and `msgUserName`. An eavesdropper on an `authPriv` exchange therefore learns which user is polling which engine, how often, and how long since the engine's last reboot - but not the objects or values. ## Choosing levels for two real accounts 1. **The NOC user** can issue Set requests that change device state. Give it `authPriv` with an HMAC-SHA-2 protocol and CFB128-AES-128, and make its VACM access row require `authPriv`, so a weaker request matches no row. 2. **The read-only automation account** polls counters. `authNoPriv` would give it integrity and replay protection, but `authPriv` costs little and stops counters and interface descriptions being readable on the wire, which makes it the safer default for both accounts. 3. **Use different secrets** for authentication and privacy: RFC 3414 calls one password for both "very poor security practice". The level a request asks for must also be one the user supports: RFC 3414 rejects an `authPriv` request from a user with no privacy protocol and counts it in `usmStatsUnsupportedSecLevels`.

  • What does an SNMPv3 agent do with an authPriv request from a user configured with no privacy protocol?
    RFC 3414 step 5 rejects it before authentication is even tried: the user does not support the requested `securityLevel`, so `usmStatsUnsupportedSecLevels` is incremented and an `unsupportedSecurityLevel` error is returned; a Report carrying that counter can go back if the request was reportable. The PDU is never processed.
  • Which USM authentication and privacy protocols should a new deployment choose?
    An HMAC-SHA-2 protocol from RFC 7860 - `usmHMAC192SHA256AuthProtocol` is the one every conforming implementation must support - with CFB128-AES-128 from RFC 3826. Avoid HMAC-MD5-96 and CBC-DES, whose 56-bit effective key is too short. AES-192 and AES-256 for USM have no RFC, so use them only where both ends implement the same non-standard variant.
  • Why does an authNoPriv message still stop a modified Set from being applied?
    The HMAC covers the whole serialised message, including the PDU and its values. Changing any byte without the user's localized key makes the recomputed digest differ, so USM rejects the message and counts it in `usmStatsWrongDigests`. Privacy adds secrecy, not tamper protection - authentication already provides that.

saying these in an interview costs you the question

  • authPriv hides the user name and engine ID from an eavesdropper.
  • authNoPriv encrypts the variable bindings but not the header.
  • Privacy without authentication is a valid level that saves CPU.
  • The 150-second time window also protects noAuthNoPriv messages.
  • The 96 in HMAC-SHA-96 is the key length in bits.
  • RFC 3826 defines AES-256 privacy for USM.
open as a page

In SNMPv3, what does the User-based Security Model check on each message, and what does the View-based Access Control Model decide afterwards?

level: juniorimportance: should knowfreq 30%

basics

~20 s

The 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.

open as a page

How does SNMPv3's USM turn one user's password into a different key on every agent, and what does that key localisation protect against?

level: seniorimportance: should knowfreq 20%

basics

~20 s

USM repeats the password to 1,048,576 octets and hashes it into a key, then hashes that key, the authoritative engine's snmpEngineID and the key again. Each agent stores only its localized result, so a stolen key opens no agent with a different engine ID.

open as a page

How do SNMPv3's snmpEngineBoots, snmpEngineTime and 150-second time window reject replayed messages, and which replays do they still let through?

level: seniorimportance: should knowfreq 15%

basics

~20 s

Each authenticated SNMPv3 message carries the authoritative engine's snmpEngineBoots and snmpEngineTime under the HMAC. A message with stale boots, or time more than 150 seconds off, is rejected - but a copy replayed inside that window is still accepted.

open as a page

Using SNMPv3's VACM, how would you give a NOC group read-write access and an automation account read-only access to interface objects only?

level: seniorimportance: nice to knowfreq 10%

basics

~20 s

Map each USM user to a VACM group, give the group an authPriv access row naming read, write and notify views, and build views from included and excluded OID subtrees. The automation group gets an interfaces-only read view and no write view.

open as a page