User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
obsoletes
- rfc-2574 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
updated by
- rfc-5590 — Transport Subsystem for the Simple Network Management Protocol (SNMP)
also
- std-62
Extracted elements (29)
Key localization (deriving per-engine keys from a single user password) was introduced so that compromise of a key at one authoritative SNMP engine does not compromise the user's key at other engines, while still allowing a single user password across the network.
One authoritative SNMP engine is designated per message exchange to anchor replay protection: the receiver is authoritative for Confirmed Class PDUs (requests expecting a response), and the sender is authoritative for Unconfirmed Class PDUs (traps/notifications). This avoids requiring all parties to maintain synchronized clocks.
The snmpEngineBoots/snmpEngineTime approach for timeliness was chosen to avoid any dependency on a real-time clock that ticks while the engine is powered off or on NTP. On each reboot, snmpEngineBoots is incremented from non-volatile storage and snmpEngineTime is reset to zero.
A zero-length msgUserName does not match any user entry, but it is specifically permitted and used for snmpEngineID discovery. Implementations must not reject zero-length userNames during the discovery exchange.
Time synchronization for authenticated communication is accomplished by sending an authenticated request with msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime set to zero; the authoritative engine returns a notInTimeWindow Report PDU with its current boots and time values, which the non-authoritative engine uses to synchronize (step 7b).
A non-authoritative SNMP engine must keep local notions of snmpEngineBoots, snmpEngineTime, and latestReceivedEngineTime for each authoritative SNMP engine with which it wishes to communicate, keyed by snmpEngineID.
An authoritative SNMP engine is required to maintain the values of its snmpEngineID and snmpEngineBoots in non-volatile storage.
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, for example by inserting a msgID in every message.
HMAC-MD5-96 is the first authentication protocol that MUST be supported with the User-based Security Model. HMAC-SHA-96 is another authentication protocol that SHOULD be supported.
If an authoritative SNMP engine is ever unable to determine its latest snmpEngineBoots value, then it MUST set its snmpEngineBoots value to 2147483647.
If the securityLevel specifies privacy but the user does not support both an authentication protocol and a privacy protocol, the message cannot be sent and an unsupportedSecurityLevel error indication is returned.
The Time Window, specifying the window of time in which a message is valid, is 150 seconds and is used uniformly for all users.
There is no provision for data confidentiality without both data integrity and data origin authentication. A message needs to be authenticated if privacy is in use.
Whenever the local value of snmpEngineBoots has the value 2147483647 it latches at that value and an authenticated message always causes a notInTimeWindow authentication failure. Manual intervention (physical reconfiguration with a new snmpEngineID or new secret values) is required to reset such an engine.
A USM user is defined by: userName, securityName, authProtocol (HMAC-MD5-96 or HMAC-SHA-96), authKey (not accessible via SNMP), authKeyChange/authOwnKeyChange, privProtocol (CBC-DES), privKey (not accessible via SNMP), and privKeyChange/privOwnKeyChange.
Discovery allows a non-authoritative engine to learn a remote authoritative engine's snmpEngineID by sending a noAuthNoPriv Request with zero-length msgUserName and msgAuthoritativeEngineID; the response is a Report PDU containing the authoritative engine's snmpEngineID and the usmStatsUnknownEngineIDs counter.
Each SNMP engine maintains snmpEngineID (unique engine identifier), snmpEngineBoots (reboot count since snmpEngineID was last configured), and snmpEngineTime (seconds since snmpEngineBoots was last incremented), which together form the basis of replay protection.
The Key Localization Algorithm derives a localized key Kul for user U at authoritative engine E by computing H(Ku || snmpEngineID || Ku), where H is the hash function of the authentication protocol. This ensures user keys differ across engines even when a single password is used.
The KeyChange textual convention provides a secure remote key update mechanism: the manager sends a concatenation of a random component and a delta component (computed by XOR-chaining the old key with the new key via iterated hashing), allowing key updates without employing privacy protection.
This document defines the SNMP-USER-BASED-SM-MIB (OID snmpModules 15), which includes usmStats counters (usmStatsUnsupportedSecLevels, usmStatsNotInTimeWindows, usmStatsUnknownUserNames, usmStatsUnknownEngineIDs, usmStatsWrongDigests, usmStatsDecryptionErrors), the usmUserTable, and OBJECT-IDENTITY registrations for authentication protocols (usmHMACMD5AuthProtocol at snmpAuthProtocols 2, usmHMACSHAAuthProtocol at snmpAuthProtocols 3) and privacy protocols (usmDESPrivProtocol at snmpPrivProtocols 2).
Access to the usmUserTable must be strictly controlled because it contains authentication and privacy protocol identifiers and key-change objects. An unauthorized principal gaining write access could change security parameters for any user, including changing keys to values known to the attacker.
Recommended practices include using passwords of at least 8 characters drawn from at least 64 possible characters, generating localized keys from passwords using the password-to-key algorithm rather than using short passwords directly as keys, and using different passwords for different security levels and users.
The authKey and privKey of a user are not accessible via SNMP (MAX-ACCESS not-accessible in the MIB), preventing network-based key extraction. Remote key updates are only possible via the KeyChange/OwnKeyChange mechanism, which uses the existing key as a one-way function input.
The 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.
Time synchronization state: a non-authoritative engine transitions from unsynchronized to synchronized upon receiving an authentic message from the authoritative engine (step 7b of incoming message processing), updating its local snmpEngineBoots, snmpEngineTime, and latestReceivedEngineTime. Resynchronization is triggered whenever the local snmpEngineID changes or when snmpEngineBoots of the remote engine advances beyond the local notion.
For CBC-DES privacy, the 8-byte DES key is taken from the first 8 octets of the localized privKey, and the 8-byte Initialization Vector is derived by XOR-ing the last 8 octets of the privKey with a 64-bit salt (constructed from snmpEngineBoots in the high 32 bits and a monotonically increasing 32-bit counter in the low 32 bits). The salt is placed in msgPrivacyParameters.
For HMAC-MD5-96 authentication, the authentication key (authKey) is 16 octets and the HMAC-MD5 digest is truncated to 12 octets, which are placed into the msgAuthenticationParameters field.
For HMAC-SHA-96 authentication, the authentication key (authKey) is 20 octets and the HMAC-SHA-1 digest is truncated to 12 octets, which are placed into the msgAuthenticationParameters field.
The msgSecurityParameters field in SNMPv3 messages is the BER serialization of UsmSecurityParameters: a SEQUENCE containing msgAuthoritativeEngineID (OCTET STRING), msgAuthoritativeEngineBoots (INTEGER 0..2147483647), msgAuthoritativeEngineTime (INTEGER 0..2147483647), msgUserName (OCTET STRING SIZE 0..32), msgAuthenticationParameters (OCTET STRING), and msgPrivacyParameters (OCTET STRING).