No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

S12700 V200R013C00 MIB Reference

This document provides the function overview, relationships between tables, description of single objects, description of MIB tables, and description of alarm objects.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
SNMP-USER-BASED-SM-MIB

SNMP-USER-BASED-SM-MIB

Function Overview

The MIB contains definitions of objects that belong to SNMP files based on user security mode.

The ID of the root object is:

iso(1).org(3).dod(6).internet(1).snmpV2(6).snmpModules(3).snmpUsmMIB(15)

Relationship Between Tables

None.

Description of Single Objects

usmStatsUnsupportedSecLevels

OID

Object Name

Syntax

Max Access

Description

Implemented Specifications

1.3.6.1.6.3.15.1.1.1

usmStatsUnsupportedSecLevels

Counter 32

Read-only

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.

This object is implemented as defined in the corresponding MIB files.

usmStatsNotInTimeWindows

OID

Object Name

Syntax

Max Access

Description

Implemented Specifications

1.3.6.1.6.3.15.1.1.2

usmStatsNotInTimeWindows

Counter 32

Read-only

The total number of packets received by the SNMP engine which were dropped because they appeared outside of the authoritative SNMP engine's window.

This object is implemented as defined in the corresponding MIB files.

usmStatsUnknownUserNames

OID

Object Name

Syntax

Max Access

Description

Implemented Specifications

1.3.6.1.6.3.15.1.1.3

usmStatsUnknownUserNames

Counter32

Read-only

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.

This object is implemented as defined in the corresponding MIB files.

usmStatsUnknownEngineIDs

OID

Object Name

Syntax

Max Access

Description

Implemented Specifications

1.3.6.1.6.3.15.1.1.4

usmStatsUnknownEngineIDs

Counter32

Read-only

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.

This object is implemented as defined in the corresponding MIB files.

usmUserSpinLock

OID

Object Name

Syntax

Max Access

Description

Implemented Specifications

1.3.6.1.6.3.15.1.2.1

usmUserSpinLock

TestAndIncr

Read-write

An advisory lock used to allow several cooperating Command Generator Applications to coordinate their use of facilities to alter secrets in the usmUserTable.

This object is implemented as defined in the corresponding MIB files.

usmStatsWrongDigests

OID

Object Name

Syntax

Max Access

Description

Implemented Specifications

1.3.6.1.6.3.15.1.1.5

usmStatsWrongDigests

Counter32

Read-only

The total number of packets received by the SNMP engine which were dropped because they didn't contain the expected digest value.

This object is implemented as defined in the corresponding MIB files.

usmStatsDecryptionErrors

OID

Object Name

Syntax

Max Access

Description

Implemented Specifications

1.3.6.1.6.3.15.1.1.6

usmStatsDecryptionErrors

Counter32

Read-only

The total number of packets received by the SNMP engine which were dropped because they could not be decrypted.

This object is implemented as defined in the corresponding MIB files.

Description of MIB Tables

usmUserTable

This table describes the authentication and encryption of each user.

The indexes of the table are usmUserEngineID and usmUserName.

OID

Object Name

Syntax

Max Access

Description

Implemented Specifications

1.3.6.1.6.3.15.1.2.2.1.1

usmUserEngineID

SnmpEngineID

Not-accessible

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.

Currently, the value is a string of 5 to 32 characters.

1.3.6.1.6.3.15.1.2.2.1.2

usmUserName

SnmpAdminString (SIZE(1..32))

Not-accessible

A human readable string representing the name of the user.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.3

usmUserSecurityName

SnmpAdminString

Read-only

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.

Currently, the value is a string of 1 to 32 characters.

1.3.6.1.6.3.15.1.2.2.1.4

usmUserCloneFrom

RowPointer

Read-create

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 (that is, 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 values as the corresponding secrets of the clone-from user to allow the KeyChange process to occur as required during user creation.

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.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.5

usmUserAuthProtocol

AutonomousType

Read-create

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 (that is, 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 (that is 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.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.6

usmUserAuthKeyChange

KeyChange

Read-create

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 a user is created, 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.
  3. If you do the key change on behalf of another user, SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=kcValue usmUserPublic=randomValue)
  4. If you do the key change for yourself, 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 whether the value is equal to the randomValue you sent 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.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.7

usmUserOwnAuthKeyChange

KeyChange

Read-create

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.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.8

usmUserPrivProtocol

AutonomousType

Read-create

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 (that is, 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 (that is 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.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.9

usmUserPrivKeyChange

KeyChange

Read-create

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.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.10

usmUserOwnPrivKeyChange

KeyChange

Read-create

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.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.11

usmUserPublic

OCTET STRING (SIZE(0..32))

Read-create

A publicly-readable value which is 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.

Currently, the value is a string of 1 to 32 characters.

1.3.6.1.6.3.15.1.2.2.1.12

usmUserStorageType

StorageType

Read-create

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.

This object is implemented as defined in the corresponding MIB files.

1.3.6.1.6.3.15.1.2.2.1.13

usmUserStatus

RowStatus

Read-create

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.

This object is implemented as defined in the corresponding MIB files.

Creation Limitation

The entries in this table can be created.

Modification Limitation

The entries in this table can be modified.

Deletion Limitation

The entries in this table can be deleted.

Access Limitation

The entries in this table can be read without limitation.

Description of Alarm Objects

None.

Translation
Download
Updated: 2019-04-09

Document ID: EDOC1100065666

Views: 15867

Downloads: 50

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next