>>>>> "JM" == Jeff Miller <Miller> writes: JM> - Changing the snmpd engineID will make the previous JM> localized engineID for a given security name incorrect JM> and render those users in the USM table unusable.
Dave is right, the engineID itself is not "localized". "localization" refers to how master keys (which may have been derived from a user-entered-password) are changed to they are unique "per device" by running the master key combined with a device's enigneID to produce a "localized" key which is different on every device (because each device has a different engineID, each resulting localized key will be different since that part of the input to the hash function changes per device). (sorry about that run-on sentence). JM> - The engineID in the USM table is not accessible so it JM> is not possible to reference and change it externally. It is accessible, as it's encoded into the OID and therefore a management station can see it. However, it is an index object and even if you could read it directly through a "GET" or other operation, you would still not be allow to change it through a SET because SNMP doesn't allow that (really, it's the SMIs fault not the protocols; but I digress). IE, the *only* way to change an index of any table (including the user table's engineID index column) is to delete the existing row and create a new one copying the contents of the original. JM> - The keys for a user in the USM table are one-way JM> encoded so it is not possible to determine the clear JM> text that was originally used to add the user to the JM> usm table. Correct. By design, the localized keys that are unique per device (and we store them in /var/net-snmp/snmpd.conf) will never be usable on any other system with a different engineID. JM> Given that the above is correct, then a requirement for JM> changing the snmpd engineID is that after changing it JM> you must restore the USM table using a process similar JM> to how you created the users originally, and in particular, JM> you will need to know the "in the clear" keys. Correct. The important thing here to take away: SNMPv3/USM was designed in such a way that engineIDs *should never change*. There is no reason I've ever heard of to change one, *except* if a conflict occurs (two devices share an engineID). Sadly, the recommended method defined in the SNMPv3 RFCs for auto-generating engineIDs was to use a engineID based on the IPv4 address of the device. Net-SNMP actually uses a different mechanism (by default; it can be changed) to generate engineIDs: we use a combination of the system clock time and random data to attempt to ensure that there will never be a collision. (If you use IPv4 addresses, then you're much more likely to get one; I could go into details as to why but this is getting too long as it is). Again, the important thing to take away: don't change the engineID once it's been set and you've created users for it. There is no reason to do so. (feel free to give me a reason if you think you've come up with one, but IMHO, there isn't any). JM> BTW: I do not see this as a net-snmp deficiency but more JM> of an overall fall out of how the USM, VACM, TARGET and JM> SNMP framework are loosely coupled. They're loosely coupled by design... The notion is that any of them could be replaced with a "better" system in the future without affecting the others. As an example, the ISMS group in the IETF is defining SNMP over SSH to offer an alternative to the USM framework, but is not modifying the VACM or TARGET (or other) specifications. -- Wes Hardaker Sparta, Inc. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
