McDATA 316095-B21 - StorageWorks Edge Switch 2/24, Manual

Page: 515 / 684

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