Hi Tjip, By your fix, replay attacks are possible and thus also authentication and authorization are no longer trustworthy. The end user has to decide whether a reboot of a machine without incrementing the engineBoots counter is allowed or not.
Best regards, Frank Tjip Pasma wrote: > Hi Frank > > Yes im aware that System.nanotime is a java 1.5+ feature, but since Im > using that in all our snmp manager applications then i choose to modify > to improve robustness. > > With regards to security then i have to disagree with you: > The most important snmp v3 security concepts is authentication and > encryption and > neither of these is compromised by the changes introduced in this fix. > engineTime/-Boots protects the agents from replay attacks, but as long > as the > agent isn't modified then the replay attack security remains the same. > Accepting time changes from a agent is a fix that is only applied on the > manager > side in my case, the alternative to this implementation would be to use > the snmp > timeout to call USM.removeEngineTime and then repeat the snmp request, > this is in > principle the same solution but less effective. > > Kind Regards > Tjip > > > > > > -----Original Message----- > From: Frank Fock [mailto:[email protected]] > Sent: 25. juni 2009 09:09 > To: Tjip Pasma > Cc: Stath, Paul; [email protected] > Subject: Re: [SNMP4J] When to call USM.removeEngineTime > > Hi Tjip, > > As I wrote several times on the list: > (1) SNMP4J 1.x is designed for Java 1.4, therefore System.nanoTime > cannot be used. > (2) Automatically accepting time changes from a SNMPv3 entity makes its > security concept (nearly) worthless. > You should then use SNMPv1/v2c instead. > > Best regards, > Frank > > Tjip Pasma wrote: >> Hi >> >> I attached my fixes, there is actually two problems fixed in these two > >> files. >> 1. In UsmTimeTable.checkTime there a check to see if the agents time >> have been set backwards and if it is then this new time is being >> accepted. This is where i would fix the issue with an agent reseting >> its engineBoots. >> 2. System.currentTimeMillis is replaced with System.nanoTime in misc. >> locations, >> this makes manager robust to changes in its own OS-time. >> This fix only works for java 1.5+ >> >> Its been a while since i did debugging of these issues but as far as i > >> remember then you are not able to detect this issue on a snmp4j API >> level. >> The pdu request will end in a timeout just like you also have > notiched. >> (A CounterEvent is send when this happens, so you may implement a an >> event listener that uses this event, but afair this didnt provide a >> robust and easy fix of the issues faced here) >> >> BR >> Tjip >> >> PS: if your manager rarely communicates with the agents then you may >> be facing the issue of agent time that "changes" >> If your manager reference clock is deviating with 500 ppm from the >> agents reference clock then in "just" 3,5 days the time will have >> drifted 150 seconds apart between thes two systems. >> So if you are communicating with time intervals of this size then you >> may wanna check what kind of differences you have in clock system. >> >> >> -----Original Message----- >> From: Stath, Paul [mailto:[email protected]] >> Sent: 19. juni 2009 15:25 >> To: Tjip Pasma; [email protected] >> Subject: RE: [SNMP4J] When to call USM.removeEngineTime >> >> Tjip: >> >> Thanks for your prompt reply. >> >> The devices I am managing are embedded, and don't have a real-time >> clock, so I don't have to worry about changes to the system time on >> the agents. >> >> However, I would be interested in your fix, since I have considered >> this course of action myself, and it would be nice to have a sanity > check. >> In response to your referenced link, Frank indicates that the (latest) > >> version of SNMP4J returns a Report PDU on a notInTimeWindow report. >> I'm not seeing this in the JavaDoc for SNMP4J 1.10, much less the >> latest SNMP4J back in 2008-Apr-02. (Looks like maybe v 1.21 or 1.5 >> based on >> Changelog.) >> >> Frank's response: >> http://lists.agentpp.org/pipermail/snmp4j/2008-April/002833.html >> >> I'm using SNMP4J v1.9.3d, and Snmp.send() is returning like a timeout, >> (ResonseEvent.getRespone() == null) even though Wireshark shows the >> ReportPDU being returning right away. >> >> Am I missing something? >> >> -- Paul >> >>> -----Original Message----- >>> From: Tjip Pasma [mailto:[email protected]] >>> Sent: Friday, June 19, 2009 7:08 AM >>> To: Stath, Paul; [email protected] >>> Subject: RE: [SNMP4J] When to call USM.removeEngineTime >>> >>> Hi >>> >>> This is actually an interesting case, im gonna check if Im facing >>> this >>> same case for my system..... >>> >>> Management of engineTime / engineBoots is to my experience pretty >>> flawed, as the majority of implementations that i know of, base their > >>> engineTime on their operating system time. >>> The consequence of this is that if you modify the OS-time on the >>> agent >>> then you may end up with an agent that you wont be able to talk to >>> with snmp v3. >>> (read more details here >>> http://lists.agentpp.org/pipermail/snmp4j/2008-April/002832.html) >>> >>> I made a fix for the above case by modifying snmp4j (in >>> UsmTimeTable.checkTime, i can send you my fix if you want) so it will > >>> allow an agent to use an engineTime's with a lower value than >>> expected >>> by checkTime. I would suggest that you modified in a similar way to >>> allow the specific case of an engineBoots of 1. (some would claim >>> that >>> this violates usm security for snmp v3, however i see this as >>> increasing the robustness of snmp v3 :-) >>> >>> Best Regards >>> Tjip Pasma >>> >>> >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Stath, Paul >>> Sent: 18. juni 2009 21:55 >>> To: [email protected] >>> Subject: [SNMP4J] When to call USM.removeEngineTime >>> >>> I am using snmp4J in a long running program that performs SNMP >>> management functions. >>> >>> The devices that we are managing store the value for engineBoots in >>> non-vol. >>> >>> If the device is reset to factory default (by removing the non-vol >>> files) the value for >>> msgAuthoritativeEngineBoots becomes "1" when the device is rebooted. >>> >>> If snmp4j has already discovered the values for engineBoots and >>> engineTime for this device, any further USM PDU messages return a >>> REPORT PDU indicating that the msgAuthoritativeEngineTime provided by > >>> snmp4j is wrong. When this occurs, the device is unmanageable until >>> the program is restarted. >>> >>> The removeEngineTime() method of the USM object appears to address >>> this problem, if I can get it called. >>> >>> The ResposeEvent returned from Snmp.send(pdu, target) returns a null >>> value for getResponse(). >>> >>> If getReponse() would return the REPORT PDU, I could call >>> removeEngineTime() and resend the PDU. >>> >>> If I'm using TableUtils, the RetrievalEvent has a >>> getReportPDU() method that returns a REPORT PDU. >>> >>> Given that I need to clear the engineTime values for an already >>> discovered agent, what are my options, and which is cleanest? >>> >>> 1) Implement my own object with a send() method that returns a >>> RetrievalEvent rather than a ResponseEvent? >>> >>> 2) Implement an AuthenticationFailureListener class that listens for >>> AuthenticationFailureEvent messages and clears the engineTimes, >>> allowing the retry in MessageDispatherImpl to retry the PDU? >>> (This would require parsing the BERInputSteam to determine the >>> specific error, and get the engineID.) >>> >>> 3) Something else? >>> >>> -- Paul Stath >>> _______________________________________________ >>> SNMP4J mailing list >>> [email protected] >>> http://lists.agentpp.org/mailman/listinfo/snmp4j >>> >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> _______________________________________________ >>> SNMP4J mailing list >>> [email protected] >>> http://lists.agentpp.org/mailman/listinfo/snmp4j > -- AGENT++ http://www.agentpp.com http://www.snmp4j.com http://www.mibexplorer.com http://www.mibdesigner.com _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
