[SNMP4J] When to call USM.removeEngineTime
Tjip Pasma
tjip.pasma at ericsson.com
Thu Jun 25 15:34:29 CEST 2009
Hi Frank
Well, replay attacks is mostly a concern for agents and the agent isn't
modified in this case.
(Im not an expert in replay attack though :-).
It's not really possible to execute a replay attack towards a
manager as managers always initiates communication.
Kind Regards
Tjip
-----Original Message-----
From: Frank Fock [mailto:fock at agentpp.com]
Sent: 25. juni 2009 14:58
To: Tjip Pasma
Cc: Stath, Paul; snmp4j at agentpp.org
Subject: Re: [SNMP4J] When to call USM.removeEngineTime
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:fock at agentpp.com]
> Sent: 25. juni 2009 09:09
> To: Tjip Pasma
> Cc: Stath, Paul; snmp4j at agentpp.org
> 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:PStath at axxcelera.com]
>> Sent: 19. juni 2009 15:25
>> To: Tjip Pasma; snmp4j at agentpp.org
>> 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:tjip.pasma at ericsson.com]
>>> Sent: Friday, June 19, 2009 7:08 AM
>>> To: Stath, Paul; snmp4j at agentpp.org
>>> 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: snmp4j-bounces at agentpp.org
>>> [mailto:snmp4j-bounces at agentpp.org] On Behalf Of Stath, Paul
>>> Sent: 18. juni 2009 21:55
>>> To: snmp4j at agentpp.org
>>> 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
>>> SNMP4J at agentpp.org
>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> ---
>>>
>>> _______________________________________________
>>> SNMP4J mailing list
>>> SNMP4J at agentpp.org
>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>
--
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com
More information about the SNMP4J
mailing list