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 V200R011C10 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).
usmUserTable

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.

Translation
Download
Updated: 2019-03-29

Document ID: EDOC1000178122

Views: 734142

Downloads: 36

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