Re: USM engineID and the snmpd engineID?

> >> "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.
So by using the system clock, does the engineID change at each boot?

I can still authenticate if I use the -e option on the command line using
the engineID that was set at the time the user was created. Is that a bug
or a feature?







-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users