SNMP-USER-BASED-SM-MIB

File: SNMP-USER-BASED-SM-MIB.mib (39099 bytes)

Imported modules

SNMPv2-SMI SNMPv2-TC SNMPv2-CONF
SNMP-FRAMEWORK-MIB

Imported symbols

MODULE-IDENTITY OBJECT-TYPE OBJECT-IDENTITY
snmpModules Counter32 TEXTUAL-CONVENTION
TestAndIncr RowStatus RowPointer
StorageType AutonomousType MODULE-COMPLIANCE
OBJECT-GROUP SnmpAdminString SnmpEngineID
snmpAuthProtocols snmpPrivProtocols

Defined Types

KeyChange  
Every definition of an object with this syntax must identify a protocol P, a secret key K, and a hash algorithm H that produces output of L octets. The object's value is a manager-generated, partially-random value which, when modified, causes the value of the secret key K, to be modified via a one-way function. The value of an instance of this object is the concatenation of two components: first a 'random' component and then a 'delta' component. The lengths of the random and delta components are given by the corresponding value of the protocol P; if P requires K to be a fixed length, the length of both the random and delta components is that fixed length; if P allows the length of K to be variable up to a particular maximum length, the length of the random component is that maximum length and the length of the delta component is any length less than or equal to that maximum length. For example, usmHMACMD5AuthProtocol requires K to be a fixed length of 16 octets and L - of 16 octets. usmHMACSHAAuthProtocol requires K to be a fixed length of 20 octets and L - of 20 octets. Other protocols may define other sizes, as deemed appropriate. When a requester wants to change the old key K to a new key keyNew on a remote entity, the 'random' component is obtained from either a true random generator, or from a pseudorandom generator, and the 'delta' component is computed as follows: - a temporary variable is initialized to the existing value of K; - if the length of the keyNew is greater than L octets, then: - the random component is appended to the value of the temporary variable, and the result is input to the the hash algorithm H to produce a digest value, and the temporary variable is set to this digest value; - the value of the temporary variable is XOR-ed with the first (next) L-octets (16 octets in case of MD5) of the keyNew to produce the first (next) L-octets (16 octets in case of MD5) of the 'delta' component. - the above two steps are repeated until the unused portion of the keyNew component is L octets or less, - the random component is appended to the value of the temporary variable, and the result is input to the hash algorithm H to produce a digest value; - this digest value, truncated if necessary to be the same length as the unused portion of the keyNew, is XOR-ed with the unused portion of the keyNew to produce the (final portion of the) 'delta' component. For example, using MD5 as the hash algorithm H: iterations = (lenOfDelta - 1)/16; /* integer division */ temp = keyOld; for (i = 0; i < iterations; i++) { temp = MD5 (temp || random); delta[i*16 .. (i*16)+15] = temp XOR keyNew[i*16 .. (i*16)+15]; } temp = MD5 (temp || random); delta[i*16 .. lenOfDelta-1] = temp XOR keyNew[i*16 .. lenOfDelta-1]; The 'random' and 'delta' components are then concatenated as described above, and the resulting octet string is sent to the recipient as the new value of an instance of this object. At the receiver side, when an instance of this object is set to a new value, then a new value of K is computed as follows: - a temporary variable is initialized to the existing value of K; - if the length of the delta component is greater than L octets, then: - the random component is appended to the value of the temporary variable, and the result is input to the hash algorithm H to produce a digest value, and the temporary variable is set to this digest value; - the value of the temporary variable is XOR-ed with the first (next) L-octets (16 octets in case of MD5) of the delta component to produce the first (next) L-octets (16 octets in case of MD5) of the new value of K. - the above two steps are repeated until the unused portion of the delta component is L octets or less, - the random component is appended to the value of the temporary variable, and the result is input to the hash algorithm H to produce a digest value; - this digest value, truncated if necessary to be the same length as the unused portion of the delta component, is XOR-ed with the unused portion of the delta component to produce the (final portion of the) new value of K. For example, using MD5 as the hash algorithm H: iterations = (lenOfDelta - 1)/16; /* integer division */ temp = keyOld; for (i = 0; i < iterations; i++) { temp = MD5 (temp || random); keyNew[i*16 .. (i*16)+15] = temp XOR delta[i*16 .. (i*16)+15]; } temp = MD5 (temp || random); keyNew[i*16 .. lenOfDelta-1] = temp XOR delta[i*16 .. lenOfDelta-1]; The value of an object with this syntax, whenever it is retrieved by the management protocol, is always the zero length string. Note that the keyOld and keyNew are the localized keys. Note that it is probably wise that when an SNMP entity sends a SetRequest to change a key, that it keeps a copy of the old key until it has confirmed that the key change actually succeeded.
TEXTUAL-CONVENTION    
  OCTET STRING  

UsmUserEntry  
SEQUENCE    
  usmUserEngineID SnmpEngineID
  usmUserName SnmpAdminString
  usmUserSecurityName SnmpAdminString
  usmUserCloneFrom RowPointer
  usmUserAuthProtocol AutonomousType
  usmUserAuthKeyChange KeyChange
  usmUserOwnAuthKeyChange KeyChange
  usmUserPrivProtocol AutonomousType
  usmUserPrivKeyChange KeyChange
  usmUserOwnPrivKeyChange KeyChange
  usmUserPublic OCTET STRING
  usmUserStorageType StorageType
  usmUserStatus RowStatus

Defined Values

snmpUsmMIB 1.3.6.1.6.3.15
The management information definitions for the SNMP User-based Security Model.
MODULE-IDENTITY    

usmMIBObjects 1.3.6.1.6.3.15.1
OBJECT IDENTIFIER    

usmMIBConformance 1.3.6.1.6.3.15.2
OBJECT IDENTIFIER    

usmNoAuthProtocol 1.3.6.1.6.3.10.1.1.1
No Authentication Protocol.
Status: current Access: read-only
OBJECT-IDENTITY    

usmHMACMD5AuthProtocol 1.3.6.1.6.3.10.1.1.2
The HMAC-MD5-96 Digest Authentication Protocol.
Status: current Access: read-only
OBJECT-IDENTITY    

usmHMACSHAAuthProtocol 1.3.6.1.6.3.10.1.1.3
The HMAC-SHA-96 Digest Authentication Protocol.
Status: current Access: read-only
OBJECT-IDENTITY    

usmNoPrivProtocol 1.3.6.1.6.3.10.1.2.1
No Privacy Protocol.
Status: current Access: read-only
OBJECT-IDENTITY    

usmDESPrivProtocol 1.3.6.1.6.3.10.1.2.2
The CBC-DES Symmetric Encryption Protocol.
Status: current Access: read-only
OBJECT-IDENTITY    

usmStats 1.3.6.1.6.3.15.1.1
OBJECT IDENTIFIER    

usmStatsUnsupportedSecLevels 1.3.6.1.6.3.15.1.1.1
The total number of packets received by the SNMP engine which were dropped because they requested a securityLevel that was unknown to the SNMP engine or otherwise unavailable.
Status: current Access: read-only
OBJECT-TYPE    
  Counter32  

usmStatsNotInTimeWindows 1.3.6.1.6.3.15.1.1.2
The total number of packets received by the SNMP engine which were dropped because they appeared outside of the authoritative SNMP engine's window.
Status: current Access: read-only
OBJECT-TYPE    
  Counter32  

usmStatsUnknownUserNames 1.3.6.1.6.3.15.1.1.3
The total number of packets received by the SNMP engine which were dropped because they referenced a user that was not known to the SNMP engine.
Status: current Access: read-only
OBJECT-TYPE    
  Counter32  

usmStatsUnknownEngineIDs 1.3.6.1.6.3.15.1.1.4
The total number of packets received by the SNMP engine which were dropped because they referenced an snmpEngineID that was not known to the SNMP engine.
Status: current Access: read-only
OBJECT-TYPE    
  Counter32  

usmStatsWrongDigests 1.3.6.1.6.3.15.1.1.5
The total number of packets received by the SNMP engine which were dropped because they didn't contain the expected digest value.
Status: current Access: read-only
OBJECT-TYPE    
  Counter32  

usmStatsDecryptionErrors 1.3.6.1.6.3.15.1.1.6
The total number of packets received by the SNMP engine which were dropped because they could not be decrypted.
Status: current Access: read-only
OBJECT-TYPE    
  Counter32  

usmUser 1.3.6.1.6.3.15.1.2
OBJECT IDENTIFIER    

usmUserSpinLock 1.3.6.1.6.3.15.1.2.1
An advisory lock used to allow several cooperating Command Generator Applications to coordinate their use of facilities to alter secrets in the usmUserTable.
Status: current Access: read-write
OBJECT-TYPE    
  TestAndIncr  

usmUserTable 1.3.6.1.6.3.15.1.2.2
The table of users configured in the SNMP engine's Local Configuration Datastore (LCD). To create a new user (i.e., to instantiate a new conceptual row in this table), it is recommended to follow this procedure: 1) GET(usmUserSpinLock.0) and save in sValue. 2) SET(usmUserSpinLock.0=sValue, usmUserCloneFrom=templateUser, usmUserStatus=createAndWait) You should use a template user to clone from which has the proper auth/priv protocol defined. If the new user is to use privacy: 3) generate the keyChange value based on the secret privKey of the clone-from user and the secret key to be used for the new user. Let us call this pkcValue. 4) GET(usmUserSpinLock.0) and save in sValue. 5) SET(usmUserSpinLock.0=sValue, usmUserPrivKeyChange=pkcValue usmUserPublic=randomValue1) 6) GET(usmUserPulic) and check it has randomValue1. If not, repeat steps 4-6. If the new user will never use privacy: 7) SET(usmUserPrivProtocol=usmNoPrivProtocol) If the new user is to use authentication: 8) generate the keyChange value based on the secret authKey of the clone-from user and the secret key to be used for the new user. Let us call this akcValue. 9) GET(usmUserSpinLock.0) and save in sValue. 10) SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=akcValue usmUserPublic=randomValue2) 11) GET(usmUserPulic) and check it has randomValue2. If not, repeat steps 9-11. If the new user will never use authentication: 12) SET(usmUserAuthProtocol=usmNoAuthProtocol) Finally, activate the new user: 13) SET(usmUserStatus=active) The new user should now be available and ready to be used for SNMPv3 communication. Note however that access to MIB data must be provided via configuration of the SNMP-VIEW-BASED-ACM-MIB. The use of usmUserSpinlock is to avoid conflicts with another SNMP command responder application which may also be acting on the usmUserTable.
Status: current Access: not-accessible
OBJECT-TYPE    
  SEQUENCE OF  
    UsmUserEntry

usmUserEntry 1.3.6.1.6.3.15.1.2.2.1
A user configured in the SNMP engine's Local Configuration Datastore (LCD) for the User-based Security Model.
Status: current Access: not-accessible
OBJECT-TYPE    
  UsmUserEntry  

usmUserEngineID 1.3.6.1.6.3.15.1.2.2.1.1
An SNMP engine's administratively-unique identifier. In a simple agent, this value is always that agent's own snmpEngineID value. The value can also take the value of the snmpEngineID of a remote SNMP engine with which this user can communicate.
Status: current Access: not-accessible
OBJECT-TYPE    
  SnmpEngineID  

usmUserName 1.3.6.1.6.3.15.1.2.2.1.2
A human readable string representing the name of the user. This is the (User-based Security) Model dependent security ID.
Status: current Access: not-accessible
OBJECT-TYPE    
  SnmpAdminString Size(1..32)  

usmUserSecurityName 1.3.6.1.6.3.15.1.2.2.1.3
A human readable string representing the user in Security Model independent format. The default transformation of the User-based Security Model dependent security ID to the securityName and vice versa is the identity function so that the securityName is the same as the userName.
Status: current Access: read-only
OBJECT-TYPE    
  SnmpAdminString  

usmUserCloneFrom 1.3.6.1.6.3.15.1.2.2.1.4
A pointer to another conceptual row in this usmUserTable. The user in this other conceptual row is called the clone-from user. When a new user is created (i.e., a new conceptual row is instantiated in this table), the privacy and authentication parameters of the new user must be cloned from its clone-from user. These parameters are: - authentication protocol (usmUserAuthProtocol) - privacy protocol (usmUserPrivProtocol) They will be copied regardless of what the current value is. Cloning also causes the initial values of the secret authentication key (authKey) and the secret encryption key (privKey) of the new user to be set to the same value as the corresponding secret of the clone-from user. The first time an instance of this object is set by a management operation (either at or after its instantiation), the cloning process is invoked. Subsequent writes are successful but invoke no action to be taken by the receiver. The cloning process fails with an 'inconsistentName' error if the conceptual row representing the clone-from user does not exist or is not in an active state when the cloning process is invoked. When this object is read, the ZeroDotZero OID is returned.
Status: current Access: read-create
OBJECT-TYPE    
  RowPointer  

usmUserAuthProtocol 1.3.6.1.6.3.15.1.2.2.1.5
An indication of whether messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, can be authenticated, and if so, the type of authentication protocol which is used. An instance of this object is created concurrently with the creation of any other object instance for the same user (i.e., as part of the processing of the set operation which creates the first object instance in the same conceptual row). If an initial set operation (i.e. at row creation time) tries to set a value for an unknown or unsupported protocol, then a 'wrongValue' error must be returned. The value will be overwritten/set when a set operation is performed on the corresponding instance of usmUserCloneFrom. Once instantiated, the value of such an instance of this object can only be changed via a set operation to the value of the usmNoAuthProtocol. If a set operation tries to change the value of an existing instance of this object to any value other than usmNoAuthProtocol, then an 'inconsistentValue' error must be returned. If a set operation tries to set the value to the usmNoAuthProtocol while the usmUserPrivProtocol value in the same row is not equal to usmNoPrivProtocol, then an 'inconsistentValue' error must be returned. That means that an SNMP command generator application must first ensure that the usmUserPrivProtocol is set to the usmNoPrivProtocol value before it can set the usmUserAuthProtocol value to usmNoAuthProtocol.
Status: current Access: read-create
OBJECT-TYPE    
  AutonomousType  

usmUserAuthKeyChange 1.3.6.1.6.3.15.1.2.2.1.6
An object, which when modified, causes the secret authentication key used for messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, to be modified via a one-way function. The associated protocol is the usmUserAuthProtocol. The associated secret key is the user's secret authentication key (authKey). The associated hash algorithm is the algorithm used by the user's usmUserAuthProtocol. When creating a new user, it is an 'inconsistentName' error for a set operation to refer to this object unless it is previously or concurrently initialized through a set operation on the corresponding instance of usmUserCloneFrom. When the value of the corresponding usmUserAuthProtocol is usmNoAuthProtocol, then a set is successful, but effectively is a no-op. When this object is read, the zero-length (empty) string is returned. The recommended way to do a key change is as follows: 1) GET(usmUserSpinLock.0) and save in sValue. 2) generate the keyChange value based on the old (existing) secret key and the new secret key, let us call this kcValue. If you do the key change on behalf of another user: 3) SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=kcValue usmUserPublic=randomValue) If you do the key change for yourself: 4) SET(usmUserSpinLock.0=sValue, usmUserOwnAuthKeyChange=kcValue usmUserPublic=randomValue) If you get a response with error-status of noError, then the SET succeeded and the new key is active. If you do not get a response, then you can issue a GET(usmUserPublic) and check if the value is equal to the randomValue you did send in the SET. If so, then the key change succeeded and the new key is active (probably the response got lost). If not, then the SET request probably never reached the target and so you can start over with the procedure above.
Status: current Access: read-create
OBJECT-TYPE    
  KeyChange  

usmUserOwnAuthKeyChange 1.3.6.1.6.3.15.1.2.2.1.7
Behaves exactly as usmUserAuthKeyChange, with one notable difference: in order for the set operation to succeed, the usmUserName of the operation requester must match the usmUserName that indexes the row which is targeted by this operation. In addition, the USM security model must be used for this operation. The idea here is that access to this column can be public, since it will only allow a user to change his own secret authentication key (authKey). Note that this can only be done once the row is active. When a set is received and the usmUserName of the requester is not the same as the umsUserName that indexes the row which is targeted by this operation, then a 'noAccess' error must be returned. When a set is received and the security model in use is not USM, then a 'noAccess' error must be returned.
Status: current Access: read-create
OBJECT-TYPE    
  KeyChange  

usmUserPrivProtocol 1.3.6.1.6.3.15.1.2.2.1.8
An indication of whether messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, can be protected from disclosure, and if so, the type of privacy protocol which is used. An instance of this object is created concurrently with the creation of any other object instance for the same user (i.e., as part of the processing of the set operation which creates the first object instance in the same conceptual row). If an initial set operation (i.e. at row creation time) tries to set a value for an unknown or unsupported protocol, then a 'wrongValue' error must be returned. The value will be overwritten/set when a set operation is performed on the corresponding instance of usmUserCloneFrom. Once instantiated, the value of such an instance of this object can only be changed via a set operation to the value of the usmNoPrivProtocol. If a set operation tries to change the value of an existing instance of this object to any value other than usmNoPrivProtocol, then an 'inconsistentValue' error must be returned. Note that if any privacy protocol is used, then you must also use an authentication protocol. In other words, if usmUserPrivProtocol is set to anything else than usmNoPrivProtocol, then the corresponding instance of usmUserAuthProtocol cannot have a value of usmNoAuthProtocol. If it does, then an 'inconsistentValue' error must be returned.
Status: current Access: read-create
OBJECT-TYPE    
  AutonomousType  

usmUserPrivKeyChange 1.3.6.1.6.3.15.1.2.2.1.9
An object, which when modified, causes the secret encryption key used for messages sent on behalf of this user to/from the SNMP engine identified by usmUserEngineID, to be modified via a one-way function. The associated protocol is the usmUserPrivProtocol. The associated secret key is the user's secret privacy key (privKey). The associated hash algorithm is the algorithm used by the user's usmUserAuthProtocol. When creating a new user, it is an 'inconsistentName' error for a set operation to refer to this object unless it is previously or concurrently initialized through a set operation on the corresponding instance of usmUserCloneFrom. When the value of the corresponding usmUserPrivProtocol is usmNoPrivProtocol, then a set is successful, but effectively is a no-op. When this object is read, the zero-length (empty) string is returned. See the description clause of usmUserAuthKeyChange for a recommended procedure to do a key change.
Status: current Access: read-create
OBJECT-TYPE    
  KeyChange  

usmUserOwnPrivKeyChange 1.3.6.1.6.3.15.1.2.2.1.10
Behaves exactly as usmUserPrivKeyChange, with one notable difference: in order for the Set operation to succeed, the usmUserName of the operation requester must match the usmUserName that indexes the row which is targeted by this operation. In addition, the USM security model must be used for this operation. The idea here is that access to this column can be public, since it will only allow a user to change his own secret privacy key (privKey). Note that this can only be done once the row is active. When a set is received and the usmUserName of the requester is not the same as the umsUserName that indexes the row which is targeted by this operation, then a 'noAccess' error must be returned. When a set is received and the security model in use is not USM, then a 'noAccess' error must be returned.
Status: current Access: read-create
OBJECT-TYPE    
  KeyChange  

usmUserPublic 1.3.6.1.6.3.15.1.2.2.1.11
A publicly-readable value which can be written as part of the procedure for changing a user's secret authentication and/or privacy key, and later read to determine whether the change of the secret was effected.
Status: current Access: read-create
OBJECT-TYPE    
  OCTET STRING Size(0..32)  

usmUserStorageType 1.3.6.1.6.3.15.1.2.2.1.12
The storage type for this conceptual row. Conceptual rows having the value 'permanent' must allow write-access at a minimum to: - usmUserAuthKeyChange, usmUserOwnAuthKeyChange and usmUserPublic for a user who employs authentication, and - usmUserPrivKeyChange, usmUserOwnPrivKeyChange and usmUserPublic for a user who employs privacy. Note that any user who employs authentication or privacy must allow its secret(s) to be updated and thus cannot be 'readOnly'. If an initial set operation tries to set the value to 'readOnly' for a user who employs authentication or privacy, then an 'inconsistentValue' error must be returned. Note that if the value has been previously set (implicit or explicit) to any value, then the rules as defined in the StorageType Textual Convention apply. It is an implementation issue to decide if a SET for a readOnly or permanent row is accepted at all. In some contexts this may make sense, in others it may not. If a SET for a readOnly or permanent row is not accepted at all, then a 'wrongValue' error must be returned.
Status: current Access: read-create
OBJECT-TYPE    
  StorageType  

usmUserStatus 1.3.6.1.6.3.15.1.2.2.1.13
The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the usmUserStatus column is 'notReady'. In particular, a newly created row for a user who employs authentication, cannot be made active until the corresponding usmUserCloneFrom and usmUserAuthKeyChange have been set. Further, a newly created row for a user who also employs privacy, cannot be made active until the usmUserPrivKeyChange has been set. The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified: The value of this object has no effect on whether other objects in this conceptual row can be modified, except for usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange. For these 2 objects, the value of usmUserStatus MUST be active.
Status: current Access: read-create
OBJECT-TYPE    
  RowStatus  

usmMIBCompliances 1.3.6.1.6.3.15.2.1
OBJECT IDENTIFIER    

usmMIBGroups 1.3.6.1.6.3.15.2.2
OBJECT IDENTIFIER    

usmMIBCompliance 1.3.6.1.6.3.15.2.1.1
The compliance statement for SNMP engines which implement the SNMP-USER-BASED-SM-MIB.
Status: current Access: read-only
MODULE-COMPLIANCE    

usmMIBBasicGroup 1.3.6.1.6.3.15.2.2.1
A collection of objects providing for configuration of an SNMP engine which implements the SNMP User-based Security Model.
Status: current Access: read-only
OBJECT-GROUP