An USM User associates SNMPv3 security parameters with a user name. RFC 3414 describes how the use of the User Security Model (USM) protects SNMPv3 communication against classic threads against network protocols.
A resource is commonly secured by password protection. However, the administrative overhead for using a different password for each network device is big. On the other hand, using a single password for all network devices is very dangerous; because once an attacker has deciphered the password it compromises all devices in the network. As a consequence, the USM security model localizes a plain text password with a SNMP entity's engine ID using a hashing algorithm. The resulting key is no longer human readable and even if it is deciphered it provides only access to a single SNMP entity. Nevertheless, changing the secrets of a USM user on a regular basis is required to protect the secrets against disclosure, as stated in RFC 3414 §11.1 Recommended Practices:
The frequency with which the secrets of a User-based Security Model user should be changed is indirectly related to the frequency of their use. Protecting the secrets from disclosure is critical to the overall security of the protocols. Frequent use of a secret provides a continued source of data that may be useful to a cryptanalyst in exploiting known or perceived weaknesses in an algorithm. Frequent changes to the secret avoid this vulnerability.
MIB Explorer provides all necessary operations to:
create a new USM user by cloning it from an existing user on the agent
modifying the secret keys (i.e. changing passwords) of an USM user
on a single target and optionally also on more than one target at once.
The following two sections “Key Change” and “Multi-Target: Create or Modify USM User” refer each to one of these two key vs. password management approaches.
The first section is about key change, which includes creating new users by cloning from existing users. But different to the multi-target approach, here localized keys are used. Key change is only available if the active target’s version is “SNMPv3 /direct”.
When dealing with multiple targets, localized keys cannot be used. Instead the active user and the new/modified user’s secrets need to be provided as passphrases. Therefore, this option is available for targets with version “SNMPv3 /USM” without localized key only.
The key change menu is available if the active target is a “direct user target” with version “SNMPv3 /direct”.
The USM key change uses the active target (see Selecting the Active Target) to modify the same or another USM user in the target’s user based security model (USM).
As shown by Figure 17, there are the following attributes required to do a key change:
Security Name
The security name of an existing user (= modifying) in the active target or the new user (= cloning). By pressing the label button, you can select a security name from existing users of the active target.
Engine ID
The engine ID for the new user. Typically, this is the engine ID of the target which is the authoritative engine ID for command responder. The engine ID differs from that target engine ID, if the user is supposed send requests to other command responders, i.e. INFORM, GET, GETNEXT, GETBULK, or SET requests.
To select an engine ID from the engine IDs in the target already associated to any security name (using usmUserSecurityName OID) use the label button.
Providing an empty engine ID will use the engine ID of the target (or discover it, if it is not known yet).
Authentication
Protocol
The authentication protocol for the new user which is mandatory.
Passsphrase
Any character sequence with more than 8 bytes length. This sequence will be localized with the provided Engine ID.
Privacy
Protocol
The optional privacy protocol. If the user must not use privacy, leave it empty.
Passphrase
Any character sequence with more than 8 bytes length. This sequence will be localized with the provided Engine ID using the selected authentication protocol. For best interoperability, make sure that the key length produced by the authentication protocol is greater or equal to the required key length of the selected privacy protocol. For AES256, for example, use at least SHA256.
Access
If a new USM user is created in an agent within the usmUserTable, that user is not mapped to a view group in the View Access Control Model (VACM) of the agent. Therefore the user cannot be used with SNMP requests. To solve this issue, you can check this option, to copy the VACM group of the active target’s user (= the operational user) and assign the new user to that group.
With this option checked, the new user will be allowed to access the same objects than the operational user. Otherwise, no access will be granted.
New Target Name
Specifies the name of the new target in MIB Explorer that this key change operation will create for you. The name must not be assigned to any other target yet.
20.1.2Diffie Hellman (DH) Key Change
By using the Diffie Helllman (DH) key change, MIB Explorer will itself compute the new authentication and optionally privacy keys based on shared keys computed on agent and MIB Explorer side individually. That means that the new keys are not send over the wire, instead each side can compute the shared keys based on public keys received from the peer.
To run a DH key change, the following prerequisites must be met:
Agent must support DH Key Exchange by RFC 2786, for example SNMP4J-Agent 3.3.4 or later.
Agent contains a user with the desired authentication and (optional) privacy protocol with a known keys to be modified/updated. The user whose keys should be exchanged can be different to the user running the operation (which is the user of the active target).
With the label buttons of input fields you can select available values from the target agent. Entering or selecting other values might only make sense when debugging an agent.
After having select the security name, authentication protocol and optionally the privacy protocol of the user to update, press the button Execute Diffie Hellman Key Change to run the change on the agent.
Within MIB Explorer, no configuration data will have been updated so far. To update the active target (or create a new target) with the new keys, you need to press the button Create Target or Update Target.
Pressing Cancel after the key change, might result in not being able to access the agent anymore unless you have copied/saved the new keys by other means than updating the active target or creating a new one.
To not change, MIB Explorer’s configuration, press Cancel.
|
|
20.2Multi-Target: Create or Modify USM User
A new USM user is created via SNMP by cloning it from an existing user. Thus, an initial user has to be configured for each SNMP command responder (agent) by other means than SNMP, for example a configuration file. The authentication and privacy passwords of an USM user should be always changeable.
To Create an USM User
Note: A user cannot provide a higher security level than the user it has been cloned from.
1.If not done yet, configure the target(s) for which the new user should be created (see Adding a New Target). For each of the targets, configure the USM user you want the new user to be cloned from (see Adding an USM User).
2.Choose Create/Modify SNMPv3 User from the Edit menu.
3.Select as User for Operation the user configured in step 1, thus the user you want the new user to be cloned from.
4.Specify all necessary values for the user to be created in the User to Be Created/Modified pane. Fill in a SNMP engine ID, if the user should be created on behalf of an engine ID different from the targets engine ID. This is necessary for setting up a user for enabling a target to send INFORM messages or to proxy SNMP requests to other targets. In all other cases, the engine ID field can be left empty.
5.For very specific tasks it could be useful to check the Do not modify operational user option. When checked, the user information of MIB Explorer will not be changed trough the operation, thus the cloned user will not be added to the user repository of MIB Explorer.
6.Check the Copy VACM group for new user from operation user option, if you want to assign the same access rights of the operational user to the new user. Otherwise leave it unchecked. Then the new user will have no access rights unless the agents VACM is updated as needed.
7.Press the Next button to get to the next step of the wizard.
8.Select the targets you want the new user to be created for from the Available Targets table. It shows all targets for which the selected operational user (specified in step 3) is configured. Press the Add button to add the selected target to the list of targets to be changed.
9.Press the Finish button to start the creation of the new user.
10.The status of the operation will be shown in step 3 of the wizard. You cancel the operation by pressing the Stop button. For each target the status is shown in a table.
The new user will be added to MIB Explorer's user configuration. The configuration of the changed targets will not be changed.
11.Close the wizard by pressing the Close button.
To Modify an USM User
1.If not done yet, configure the target(s) for which a user should be modified (see Adding a New Target). Configure for each of the targets the USM user you want modify (see Adding an USM User).
2.Choose Create/Modify SNMPv3 User from the Edit menu.
3.Select as User for Operation the user configured in step 1, thus the user to be modified.
4.Change the properties of the user to be modified in the „User to Be Created/Modified“ pane. Select the same user in both User fields! Fill in a SNMP engine ID, if the user is modified on behalf of an engine ID different from the targets engine ID. This is necessary for enabling a target to send INFORM messages or to proxy SNMP requests to other targets.
Warning: When checking the Do not modify or add local user option, make sure that you have configured a user with the new credentials or otherwise you will not be able to access the agent(s) any more!
5.For very specific tasks it could be useful to check the Do not modify operational user option. When checked, the user information of MIB Explorer user specified on the left side will not be changed trough the operation! As a consequence, after having successfully changed the users security credentials, you might not be able to access the agent(s) with the user you have chosen for the operation.
6.Press the Next button to get to the next step of the wizard.
7.Select the targets for which you want the user to be modified from the Available Targets table. It shows all targets for which the selected operational user (specified in step 3) is configured. Press the Add button to add the selected target to the list of targets to be changed.
8.Press the Finish button to start the creation of the new user.
9.The status of the operation will be shown in step 3 of the wizard. You cancel the operation by pressing the Stop button. For each target the status is shown in a table.
If the operation failed or was canceled for any of the selected targets, MIB Explorer will add a new user to MIB Explorer's configuration with the current date and time appended to the user profile name of the modified user. That new user will be an exact clone of the original (unmodified) user profile. Each failed target will then be automatically configured to use the clone user, whereas each successfully updated target will use the modified user.
10. Close the wizard by pressing the Close button.
To delete an USM user:
1.Open the usmUserTable with the MIB Tree Panel’s context menu Table.
2.Select the row of the user you want to delete.
3.Set the value of the RowStatus column to destroy(6).
4.Press Commit & Verify.