snmpv3 new user!

[Jochen Katz]

Hi,

> even with that I couldn't create a new user!...I don't know what do I do wrong.
> I try to create a v3 new user with authentication as follow:
> 
> CreateAndWait:
> snmpset -v3 -p 4700 -l authNoPriv -u MD5 -a MD5 -A MD5UserAuthPassword localhost
> snmpModules.15.1.2.2.1.13.24.48.48.48.48.48.48.54.51.48.48.48.48.48.48.65.49.57.54.56.52.48.55.57.67.6.75.104.97.108.105.102
> i 5

ok, this creates a new row, that is not ready for service.

> Clone from MD5 user:
> snmpset -v3 -p 4700 -l authNoPriv -u MD5 -a MD5 -A MD5UserAuthPassword localhost
> snmpModules.15.1.2.2.1.4.24.48.48.48.48.48.48.54.51.48.48.48.48.48.48.65.49.57.54.56.52.48.55.57.67.6.75.104.97.108.105.102
> o .1.3.6.1.6.3.15.1.2.2.1.3.12.128.0.19.112.5.115.117.110.50.54.18.92.3.77.68.53

ok, the user is cloned. And the first bug: The row should stay "not
ready for service" until the KeyChange-object for this row is set. 

> setting authentication protocol (usmHMACMD5AuthProtocol):
> snmpset -v3 -p 4700 -l authNoPriv -u MD5 -a MD5 -A MD5UserAuthPassword localhost
> snmpModules.15.1.2.2.1.5.24.48.48.48.48.48.48.54.51.48.48.48.48.48.48.65.49.57.54.56.52.48.55.57.67.6.75.104.97.108.105.102
> o .1.3.6.1.6.3.10.1.1.2

Second bug: This should return an inconsistentValue error, as rfc2574
states:
                 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.

The value of this object is set through the cloning process, you're not
allowed to set it to anything other than usmNoAuthProtocol.

> setting AuthKeyChange:(new password)
> snmpset -v3 -p 4700 -l authNoPriv -u MD5 -a MD5 -A MD5UserAuthPassword localhost
> snmpModules.15.1.2.2.1.6.24.48.48.48.48.48.48.54.51.48.48.48.48.48.48.65.49.57.54.56.52.48.55.57.67.6.75.104.97.108.105.102
> s khalifmasoudtest

This is the cause of the problem. See my explanations below...

> setting the public (is this nessessery?):
> snmpset -v3 -p 4700 -l authNoPriv -u MD5 -a MD5 -A MD5UserAuthPassword localhost
> snmpModules.15.1.2.2.1.11.24.48.48.48.48.48.48.54.51.48.48.48.48.48.48.65.49.57.54.56.52.48.55.57.67.6.75.104.97.108.105.102
> s randomValue2

This object is only needed to detect errors during key changes. The
manager should set the keyChange and the public objects in one set
request. If he doesn't get a response he can get the public object and
knows wether his set request was successful or not. (see description of
MIB object usmUserAuthKeyChange in rfc 2574 for more details)

> Activate the row:
> snmpset -v3 -p 4700 -l authNoPriv -u MD5 -a MD5 -A MD5UserAuthPassword localhost
> snmpModules.15.1.2.2.1.13.24.48.48.48.48.48.48.54.51.48.48.48.48.48.48.65.49.57.54.56.52.48.55.57.67.6.75.104.97.108.105.102
> i 1

ok.

> as you see the new user has the distance engineID , I clone row MD5 which already exist and is active...everything
> seems ok, even new row become active but the big problem is , it doesnt accept my
> AuthPassword(khalifmasoudtest), but if I  double the length av password then it is accepted!!why??I have the same
> user in Masteragent with same password!!

The cause of the problem is that this object does not expect a password,
but a key change value. This value has a fixed length of 32 bytes for
MD5 and is generated from the old localized key and the new localized
key (that is generated from the new password and the engine id). The
UCD-snmp has the tool snmpusm to change keys. 

> something else which is worth to mention is , you can activate the row of new user in any way you want!! dosn't
> matter if you have all the values or not !(should it be like that!!).

No. At the moment only the cloneFrom needs to be set to activate a row.
RFC2574 states that if the new user uses authentication or privacy these
keys must be changed before the row can be activated. 

With these informations you should be able to add a new user and change
the password. And I've got some things to fix...

Best regards,
  Jochen