User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
obsoleted by
- rfc-2574 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
obsoletes
- rfc-2264 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
Extracted elements (29)
Key localization derives a per-engine secret Kul by hashing Ku || snmpEngineID || Ku (enveloping the engine ID between two copies of the user key). This ensures that even if a user uses the same password everywhere, the actual shared secret differs per authoritative engine, preventing cross-engine replay attacks.
The authoritative SNMP engine role is assigned based on message type: the receiver is authoritative for request-response exchanges (Get, Set, Inform), and the sender is authoritative for unidirectional messages (Trap, Response, Report). This ensures timeliness parameters are anchored to a single definitive source per exchange.
The CBC-DES privacy protocol is described in a self-contained section to reflect its replaceable nature; the USM architecture explicitly anticipates that future authentication and privacy protocols can be added or substituted without changing the core security model.
The security model deliberately does not protect against denial-of-service or traffic analysis. DoS attacks are largely indistinguishable from normal network failures that management protocols must tolerate anyway, and traffic patterns in SNMP are predictable and regular, making traffic analysis protection of low value.
The snmpEngineBoots+snmpEngineTime pair provides timeliness without requiring a non-volatile clock. On each reboot, snmpEngineBoots is incremented in non-volatile storage and snmpEngineTime restarts from zero, making replay across reboots detectable without NTP or persistent timekeeping hardware.
A non-authoritative engine that receives a Trap or Report intended for a different non-authoritative engine may accept it (updating timeliness state), but any Response or Report without a matching outstanding Request will be discarded by the Message Processing Model, not USM. This cross-engine replay of Traps is considered acceptable, not a threat.
The same userName can be defined on multiple SNMP engines. Because key localization produces different authKey and privKey values at each authoritative engine, users must manage separate localized secrets per engine even when a single password is used as the source material.
A message MUST NOT be sent with privacy (confidentiality) protection unless both an authentication protocol and a privacy protocol are configured for the user. Privacy without authentication is disallowed.
An authoritative SNMP engine is REQUIRED to maintain the values of snmpEngineID and snmpEngineBoots in non-volatile storage so they survive reboots.
An SNMP engine MUST use a mechanism (e.g., msgID) to match incoming Responses to outstanding Requests and MUST drop any Response that does not match an outstanding Request.
HMAC-MD5-96 MUST be supported as the first authentication protocol with the User-based Security Model. HMAC-SHA-96 SHOULD also be supported.
If an authoritative SNMP engine is ever unable to determine its latest snmpEngineBoots value, it MUST set snmpEngineBoots to 2147483647, forcing a manual reset before authenticated communication can resume.
The authKey and privKey user attributes are NOT accessible via SNMP; they are private secrets stored only in the local configuration datastore.
The Time Window for message timeliness validation is fixed at 150 seconds for all users. Messages whose generation time falls outside this window are rejected as inauthentic.
When snmpEngineBoots reaches the maximum value of 2147483647, it latches at that value and every authenticated message causes a notInTimeWindow error; manual physical intervention is required to reset the engine.
A USM user record includes: userName, securityName, authProtocol (HMAC-MD5-96 or HMAC-SHA-96), authKey (localized), authKeyChange/authOwnKeyChange, privProtocol (CBC-DES), privKey (localized), and privKeyChange/privOwnKeyChange. Keys are localized per authoritative engine and differ across engines.
The KeyChange textual convention defines a manager-generated random+delta OCTET STRING that allows secure remote key updates without requiring privacy protection. The delta is computed by XORing hash-chained values with the new key, using the existing key as the hash seed.
The USM authentication service exposes two abstract primitives: authenticateOutgoingMsg(authKey, wholeMsg) returning authenticatedWholeMsg, and authenticateIncomingMsg(authKey, authParameters, wholeMsg) returning authenticatedWholeMsg. These decouple the authentication module from the core USM procedures.
The USM privacy service exposes two abstract primitives: encryptData(encryptKey, dataToEncrypt) returning encryptedData and privParameters, and decryptData(decryptKey, privParameters, encryptedData) returning decryptedData. These isolate the privacy module implementation.
The usmUserTable (OID usmUser 2) is indexed by usmUserEngineID and usmUserName and stores per-user authentication and privacy configuration including protocol selection, key material (as KeyChange objects), clone-from pointer, storage type, and row status.
USM defines six read-only Counter32 statistics objects: usmStatsUnsupportedSecLevels, usmStatsNotInTimeWindows, usmStatsUnknownUserNames, usmStatsUnknownEngineIDs, usmStatsWrongDigests, and usmStatsDecryptionErrors. Each is incremented when the corresponding error causes a message to be dropped.
This document defines the SNMP-USER-BASED-SM-MIB MODULE-IDENTITY at OID snmpModules 15 (correcting a clerical error from RFC 2264). It registers usmNoAuthProtocol (snmpAuthProtocols 1), usmHMACMD5AuthProtocol (snmpAuthProtocols 2), usmHMACSHAAuthProtocol (snmpAuthProtocols 3), usmNoPrivProtocol (snmpPrivProtocols 1), and usmDESPrivProtocol (snmpPrivProtocols 2).
A conformant implementation MUST support at minimum noAuthNoPriv and authNoPriv security levels; authPriv support requires both an authentication and a privacy protocol to be configured for the user. Implementations MUST correctly enforce these level requirements rather than silently downgrading.
Data confidentiality cannot be obtained without both data integrity and data origin authentication; and data origin authentication cannot be obtained without data integrity. The security services form a strict hierarchy enforced by the protocol procedures.
Section 11 recommends that authKeys and privKeys be generated using the password-to-key algorithm (Appendix A.2), that each user have a unique password, and that passwords not be trivially guessable. It also warns that SNMP SET operations using USM are vulnerable to serialization attacks unless snmpSetSerialNo is used in concert.
The principal threats USM addresses are modification of in-transit messages and masquerade (impersonation). Secondary threats with limited protection are disclosure (eavesdropping) and message stream modification (replay/reordering beyond normal network behavior). DoS and traffic analysis are explicitly out of scope.
Time synchronization state for a non-authoritative engine: upon receiving an authentic message, if msgAuthoritativeEngineBoots is greater than the local notion, or equal with greater msgAuthoritativeEngineTime than latestReceivedEngineTime, update local boots, time, and latestReceivedEngineTime. Messages with boots less than local, or same boots but time more than 150s behind, are rejected as outside the Time Window.
USM discovery proceeds in two phases: (1) send noAuthNoPriv Request with empty msgAuthoritativeEngineID and userName 'initial' to obtain the authoritative engine's snmpEngineID via a Report PDU; (2) send an authenticated Request with the learned snmpEngineID and zero boots/time to trigger time synchronization, which the engine performs automatically in step 7b of the incoming message procedure.
The UsmSecurityParameters field in SNMPv3 messages is the BER serialization of an ASN.1 SEQUENCE with six fields: msgAuthoritativeEngineID (OCTET STRING), msgAuthoritativeEngineBoots (INTEGER 0..2147483647), msgAuthoritativeEngineTime (INTEGER 0..2147483647), msgUserName (OCTET STRING SIZE 1..32), msgAuthenticationParameters (OCTET STRING), and msgPrivacyParameters (OCTET STRING). This structure is encoded as the msgSecurityParameters field value.