FW 08.01.00 McDATA E/OS SNMP Support Manual (620-000131-630, November 2005)

SNMPv3 MIB

G-15

SNMPv3 MIB

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.

DEFVAL { ''H } -- the empty string

Sequence

::= { usmUserEntry 6 }

usmUserOwnAuthKeyChange

Syntax KeyChange -- typically (SIZE (0 | 32)) for HMACMD5

-- typically (SIZE (0 | 40)) for HMACSHA

Max Access read-create

Status current

Description 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.