[SNMP4J] SNMPv3 engineBoots/engineTime issue

[Brian Weaver]

Frank,

I think you missed the point. During engine discover in the situation that was originally described, SNMP4J sent a discovery packet. The manager then responded with a packet contain three key items: engine id, engine boots, and engine time. Then SNMP4J discarded two of the three values before sending another packet which resulted in the same return triple tuple.

Jochen stated that both the engine boots and engine time were discarded because not doing was insecure. Well if you can't accept two of the three values then why accept any of them? The worst that can happen is denial of service by having the wrong triple tuple that the manager uses to determine timeliness. Any encrypted data is still encrypted because the USM uses a shared private key. Any attacker wishing to decode the information would need the shared secret to decrypt the data.

From section 1.1 of RFC 3414 it states

"There are at least two threats that an SNMP Security Model need not
   protect against.  The security protocols defined in this memo do not
   provide protection against:

   - Denial of Service This SNMP Security Model does not attempt to
     address the broad range of attacks by which service on behalf of
     authorized users is denied.  Indeed, such denial-of-service attacks
     are in many cases indistinguishable from the type of network
     failures with which any viable network management protocol must
     cope as a matter of course.
"
So if the RFC states that a denial of service is out of scope then I find it difficult to accept that net-snmp's model of accept the initial SNMP engine id, boots, and time to be insecure within the specifications boundaries. 

-- Brian


On Aug 10, 2010, at 4:51 PM, Frank Fock wrote:

> Hi Brian,
> Well, why are you using SNMPv3 then? Without security, SNMPv1 is sufficient. The Engine ID Discovery can be disabled in SNMP4J to not accidentially learn a wrong engine ID.
> 
> Best regards,
> Frank
> 
> Am 10.08.2010 um 22:13 schrieb Brian Weaver <cmdrclueless at gmail.com>:
> 
>> OK, I'll give you that it might be insecure, but if you are going to yell "insecure" then why even accept the Engine ID from initial query? If someone is monitoring traffic (man in the middle) is it not just as likely they can give you the wrong Engine ID too.
>> 
>> Regards,
>> 
>> Brian
>> 
>> On Aug 10, 2010, at 3:54 PM, Jochen Katz wrote:
>> 
>>> Hi,
>>> 
>>> please see Franks recent response with subject "Initial SNMPv3 handshake
>>> extra step?"
>>> 
>>>> Can SNMP4J be configured to have similar behavior?  Not only is the
>>>> Net-SNMP behavior more efficient
>>> 
>>> but also it is insecure! If you are using SNMPv3 without authentication,
>>> the NET-SNMP behaviour is ok, as everybody who is able to sniff and
>>> insert packets can send valid responses.
>>> 
>>> But if you are using authentication, the NET-SNMP behaviour allows an
>>> attacker to prevent all communication between agent and manager. He just
>>> has to answer with an unknownEngineID report with very high boot
>>> counter. If the manager accepts this unauthenicated report it won't be
>>> able to communicate with the agent.
>>> 
>>> Regards,
>>> Jochen
>>> _______________________________________________
>>> 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