User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
obsoleted by
- rfc-2274 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
Extracted elements (29)
Key localization (binding Ku to a specific snmpEngineID via hashing) ensures that compromise of a user's key at one SNMP engine does not compromise that user's communications with other engines, even though the user may use a single password across the network.
The security protocol is designed to not depend on the availability of external network services such as NTP or key management protocols, so that management still functions during network stress conditions when such services may be unreachable.
The use of snmpEngineBoots plus snmpEngineTime eliminates the need for a non-volatile 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 monotonic progress without requiring battery-backed real-time clocks.
Data confidentiality cannot be obtained without both data integrity and data origin authentication. The USM model enforces this by requiring that any message sent with privacy (securityLevel authPriv) must also be authenticated; a privacy-without-authentication configuration is not permitted.
The timeliness check (150-second window) is only performed when authentication is applied to the message. Unauthenticated messages receive no timeliness validation, making replay protection contingent on enabling authentication.
A message MUST NOT be sent with privacy protection if the user does not support both an authentication protocol and a privacy protocol. An error indication (unsupportedSecurityLevel) MUST be returned in that case.
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 to match incoming Responses to outstanding Requests and MUST drop any Responses that do not match an outstanding request, as an additional defense against replay.
If the extracted msgAuthoritativeEngineID is the engine's own snmpEngineID and snmpEngineBoots is 2147483647, or msgAuthoritativeEngineBoots differs from local snmpEngineBoots, or msgAuthoritativeEngineTime differs by more than ±150 seconds, the message is outside the Time Window and MUST be rejected with notInTimeWindow.
The HMAC-MD5-96 authentication protocol MUST be supported with the User-based Security Model. The HMAC-SHA-96 authentication protocol SHOULD be supported.
Whenever snmpEngineBoots reaches the value 2147483647, it latches at that value and every authenticated message causes a notInTimeWindow authentication failure. Manual intervention (physical reconfiguration) is required to reset the engine.
CBC-DES privacy uses an 8-byte DES key taken from the first 8 octets of the 16-octet localized privKey; the IV is formed by XORing the remaining 8 octets of privKey with an 8-octet salt (4-byte snmpEngineBoots || 4-byte integer counter) carried in msgPrivacyParameters. The scopedPDU is padded to a multiple of 8 octets before encryption.
Discovery allows a non-authoritative engine to learn the authoritative engine's snmpEngineID by sending a Request with securityLevel noAuthNoPriv, msgUserName 'initial', zero-length msgAuthoritativeEngineID, and empty varBindList. The authoritative engine replies with a Report PDU containing its snmpEngineID and the usmStatsUnknownEngineIDs counter.
HMAC-MD5-96 authentication computes an HMAC-MD5 over the whole SNMP message (with msgAuthenticationParameters zeroed) using the 16-octet localized authKey, then truncates the result to 12 octets placed into msgAuthenticationParameters.
HMAC-SHA-96 authentication computes an HMAC-SHA-1 over the whole SNMP message (with msgAuthenticationParameters zeroed) using the 20-octet localized authKey, then truncates the result to 12 octets placed into msgAuthenticationParameters.
Key localization produces a per-engine secret Kul = H(Ku || snmpEngineID || Ku), where Ku is derived from the user's password via a password-to-key algorithm and H is the hash function of the user's authentication protocol (MD5 or SHA). This ensures different secrets at each authoritative SNMP engine even when a user uses a single password.
The authoritative SNMP engine for a message exchange is the receiver for PDUs expecting a response (Get, GetNext, GetBulk, Set, Inform) and the sender for PDUs not expecting a response (SNMPv2-Trap, Response, Report). This designation determines which engine's snmpEngineBoots/snmpEngineTime values are used for timeliness.
The KeyChange textual convention enables secure remote key update without privacy protection. A manager sends a random component concatenated with a delta component (XOR of new key with hash of old key and random), allowing only a party knowing the old key to derive the new key.
The non-authoritative SNMP engine maintains per-authoritative-engine state: a local notion of snmpEngineBoots, snmpEngineTime, and latestReceivedEngineTime. The latestReceivedEngineTime prevents replay attacks that would cause the local time notion to regress.
The Time Window is fixed at 150 seconds for all users. A received message whose generation time (as indicated by msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime) falls outside this window is considered inauthentic and is dropped.
The usmUserTable stores per-user security configuration indexed by (usmUserEngineID, usmUserName), with columns for securityName, cloneFrom pointer, authProtocol, authKeyChange, ownAuthKeyChange, privProtocol, privKeyChange, ownPrivKeyChange, storageType, and rowStatus. authKey and privKey are not accessible via SNMP.
Time synchronization can be bootstrapped after learning the remote snmpEngineID by sending an authenticated Request with msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime set to zero. The authoritative engine replies with a Report PDU containing current boots/time values, and the receiver updates its local cache per section 3.2 step 7b.
Authentication protocol OIDs are defined under snmpAuthProtocols: usmNoAuthProtocol (::= {snmpAuthProtocols 1}), usmHMACMD5AuthProtocol (::= {snmpAuthProtocols 2}), usmHMACSHAAuthProtocol (::= {snmpAuthProtocols 3}). Privacy protocol OIDs under snmpPrivProtocols: usmNoPrivProtocol (::= {snmpPrivProtocols 1}), usmDESPrivProtocol (::= {snmpPrivProtocols 2}).
This document defines the SNMP-USER-BASED-SM-MIB (OID snmpModules 4) including the usmStats counter group (usmStatsUnsupportedSecLevels, usmStatsNotInTimeWindows, usmStatsUnknownUserNames, usmStatsUnknownEngineIDs, usmStatsWrongDigests, usmStatsDecryptionErrors) and the usmUserTable for managing USM users.
Section 11 recommends that passwords be at least 8 characters, that different passwords be used for authentication and privacy protocols, and that authKey and privKey (as localized keys) be considered sensitive. It also warns that DES key length (56 bits) may be insufficient against brute-force attacks.
The authKey and privKey values are never accessible via SNMP GET operations; they can only be changed via the KeyChange mechanism, ensuring that the secrets themselves are never transmitted in cleartext over the network.
To create a new user securely, the usmUserCloneFrom mechanism is used: a new row is created cloning from an existing user, then keys are changed via KeyChange before activating the row. Creating a user with known keys by any other method introduces a window of vulnerability.
USM protects against modification of information and masquerade (principal threats), and provides limited protection against disclosure and message stream modification (replay/delay). It explicitly does not protect against denial-of-service or traffic analysis attacks.
The msgSecurityParameters field in SNMPv3 messages is the BER serialization of UsmSecurityParameters, an ASN.1 SEQUENCE containing: msgAuthoritativeEngineID (OCTET STRING), msgAuthoritativeEngineBoots (INTEGER 0..2147483647), msgAuthoritativeEngineTime (INTEGER 0..2147483647), msgUserName (OCTET STRING SIZE 1..32), msgAuthenticationParameters (OCTET STRING), and msgPrivacyParameters (OCTET STRING).