HP StorageWorks 2/140 FW 08.01.00 McDATA E/OS SNMP Support Manual (620-000131- - Page 515

SNMPv3 MIB G Sequence 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 ::= { 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. SNMPv3 MIB G-15