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 <[email protected]>:
>
>> 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
>>> [email protected]
>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>
>> _______________________________________________
>> SNMP4J mailing list
>> [email protected]
>> http://lists.agentpp.org/mailman/listinfo/snmp4j
_______________________________________________
SNMP4J mailing list
[email protected]
http://lists.agentpp.org/mailman/listinfo/snmp4j
