User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
obsoleted by
- rfc-3414 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
obsoletes
- rfc-2274 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
Extracted elements (29)
Key localization was chosen so that compromise of one engine's secrets does not expose credentials at other engines. A single global key would mean compromising any one managed device yields authentication capability for all devices that share the user's password.
The snmpEngineBoots/snmpEngineTime pair avoids requiring a persistent real-time clock that ticks while the engine is powered off. On each reboot, snmpEngineBoots is incremented in non-volatile storage and snmpEngineTime resets to zero, providing a monotonically non-decreasing time indicator without requiring battery-backed clocks.
USM was designed to require no dependency on external network services such as NTP or key management protocols. This ensures security mechanisms remain operational during network stress, which is precisely when management access is most critical.
The same userName may be defined on multiple SNMP engines with different localized keys at each. Non-authoritative engines that cache timeliness state for an authoritative engine must resynchronize (reset cached boots/time to zero) whenever the authoritative engine reboots, detected by receiving a message with a higher snmpEngineBoots value.
An authoritative SNMP engine is REQUIRED to maintain the values of its snmpEngineID and snmpEngineBoots in non-volatile storage to survive reboots.
An SNMP engine MUST use a mechanism (e.g., msgID) to match incoming Responses to outstanding Requests and MUST drop any Responses that do not match an outstanding request.
Report messages MUST be sent with a securityLevel of noAuthNoPriv, because an SNMP engine may generate Reports even when it does not know the user on whose behalf the triggering message was sent.
The HMAC-MD5-96 authentication protocol MUST be supported with the User-based Security Model.
The HMAC-SHA-96 authentication protocol SHOULD be supported with the User-based Security Model.
There is no provision for data confidentiality without both data integrity and data origin authentication; if the securityLevel requests privacy but the user lacks both authentication and privacy protocols, the message MUST NOT be sent and an unsupportedSecurityLevel error is returned.
When snmpEngineBoots reaches the value 2147483647 it latches at that value permanently, causing all subsequent authenticated messages to fail with notInTimeWindow. Manual physical reconfiguration (new snmpEngineID or new secrets for all users) is REQUIRED to reset such an engine.
A non-authoritative SNMP engine must maintain per-authoritative-engine state: local notions of snmpEngineBoots, snmpEngineTime, and latestReceivedEngineTime (keyed by snmpEngineID). Time synchronization occurs automatically in message-receive processing (Section 3.2 step 7b) when authentic messages advance the local notion of the remote engine's time.
A USM user is defined by: userName, securityName (model-independent), authProtocol (HMAC-MD5-96 or HMAC-SHA-96), authKey (private, not SNMP-accessible), privProtocol (CBC-DES), and privKey (private, not SNMP-accessible). Keys are localized per authoritative SNMP engine and updated only via authKeyChange/privKeyChange objects.
CBC-DES uses the first 8 octets of the 16-octet localized privKey as the DES encryption key (with parity bits adjusted) and the last 8 octets as the pre-IV. The actual IV is the XOR of the pre-IV with an 8-octet salt (msgPrivacyParameters), which is a monotonically increasing 64-bit integer.
Discovery is initiated by sending a Request with securityLevel noAuthNoPriv, zero-length msgUserName, and zero-length msgAuthoritativeEngineID. The authoritative engine replies with a Report PDU containing its snmpEngineID in msgAuthoritativeEngineID and the usmStatsUnknownEngineIDs counter. Time synchronization follows via a second authenticated Request with boots/time set to zero.
Each SNMP engine maintains three objects for replay protection: snmpEngineID (unique engine identifier), snmpEngineBoots (reboot count since snmpEngineID was last configured), and snmpEngineTime (seconds since snmpEngineBoots was last incremented). The authoritative engine must store snmpEngineID and snmpEngineBoots in non-volatile storage.
HMAC-MD5-96 computes HMAC-MD5 over the entire message with msgAuthenticationParameters zeroed (replaced by 12 zero octets), then truncates the 128-bit digest to the leftmost 96 bits (12 octets) as the authentication parameter. The authKey is exactly 16 octets.
HMAC-SHA-96 computes HMAC-SHA-1 over the entire message with msgAuthenticationParameters zeroed (replaced by 12 zero octets), then truncates the 160-bit digest to the leftmost 96 bits (12 octets) as the authentication parameter. The authKey is exactly 20 octets.
Key localization derives a per-engine key Kul from a master key Ku by computing H(Ku || snmpEngineID || Ku), where H is the authentication hash (MD5 or SHA). This ensures a user's secret is different at each authoritative SNMP engine even if the same password is used network-wide.
The authoritative SNMP engine for replay protection is the receiver when the message contains a Confirmed Class PDU (e.g., Get, Set), and the sender when the message contains an Unconfirmed Class PDU (e.g., Trap, Inform). Each message includes the authoritative engine's snmpEngineID to prevent cross-engine replay.
The KeyChange textual convention allows remote key updates without privacy protection. A new key value is encoded as a random component concatenated with a delta component computed by XORing hash output (seeded from oldKey || random) with successive blocks of the new key. The retrieved value is always zero-length.
The Time Window is fixed at 150 seconds for all users. Messages whose msgAuthoritativeEngineTime differs from the receiver's local notion by more than +/-150 seconds are rejected as outside the Time Window with a notInTimeWindow error.
The usmStats group defines six Counter32 error counters: usmStatsUnsupportedSecLevels, usmStatsNotInTimeWindows, usmStatsUnknownUserNames, usmStatsUnknownEngineIDs, usmStatsWrongDigests, and usmStatsDecryptionErrors. Each is incremented and its OID/value returned in error indications to allow generation of Report PDUs.
The usmUserTable is indexed by usmUserEngineID and usmUserName and stores per-engine per-user security parameters including authProtocol, authKeyChange, authOwnKeyChange, privProtocol, privKeyChange, privOwnKeyChange, usmUserCloneFrom (for key initialization), storageType, and rowStatus.
SNMP-USER-BASED-SM-MIB (snmpModules 15) defines the USM management objects, registers authentication protocol OIDs (usmNoAuthProtocol at snmpAuthProtocols 1, usmHMACMD5AuthProtocol at snmpAuthProtocols 2, usmHMACSHAAuthProtocol at snmpAuthProtocols 3) and privacy protocol OIDs (usmNoPrivProtocol at snmpPrivProtocols 1, usmDESPrivProtocol at snmpPrivProtocols 2).
Access to SNMP-USER-BASED-SM-MIB objects, particularly usmUserTable, must be carefully controlled because they contain authentication and privacy keying material. Implementations should ensure read-write access is restricted to authorized management entities only.
Recommended practices include: avoiding noAuthNoPriv in production deployments, using passwords different from system login passwords, not using obvious passwords, and ensuring managers verify key change success before discarding the old key. The usmUserTable should be treated with the same care as a system password file.
USM protects against modification of information and masquerade (principal threats) and provides limited protection against disclosure and message stream modification (replay/delay within 150 seconds). It explicitly does not protect against denial-of-service or traffic analysis, as these are indistinguishable from normal network failures or predictable management patterns.
The msgSecurityParameters field in SNMPv3 messages using USM is the BER serialization of UsmSecurityParameters: a SEQUENCE of msgAuthoritativeEngineID (OCTET STRING), msgAuthoritativeEngineBoots (INTEGER 0..2147483647), msgAuthoritativeEngineTime (INTEGER 0..2147483647), msgUserName (OCTET STRING SIZE 0..32), msgAuthenticationParameters (OCTET STRING), and msgPrivacyParameters (OCTET STRING).