Security Level Question

SNMP4J
1

When using SNMPv3, it looks like the the security level within the USM is ignored by snmp4j - both for traps and as an SNMP agent. If I create a UsmUser with, for example, AuthNoPriv, and the client only sends the security name (NoAuthNoPriv), only the security name is validated. I would have thought the USM class should validate the received security level against how the UsmUser was defined. Is this correct?

Thanks!

2

What do you mean by “the security level in USM”? From my point of view, there is no security level in the USM.
In the VACM however, an incoming request is mapped to an access entry based on the security level specified by the request. Depending on that security level, access can be granted or not.

For notification sending, the SNMP-TARGET-MIB’s table snmpTargetParamsTable is used to determine the security level of the notification.

Does that answer your question?

3

Thanks for your response!

I will concentrate on traps since that is what I was originally working on. Consider the net-snmp example for SNMPv3 traps:

createUser -e 0x8000000001020304 traptest SHA mypassword AES
authuser log traptest

snmptrap -v 3 -n “” -a SHA -A mypassword -x AES -X mypassword -l authPriv -u traptest -e 0x8000000001020304 localhost 0 linkUp.0

I have done something similar with my application using snmp4j but without the engineID and leaving engine discovery enabled (same behavior observed with informs which inverts the engine ID). In the net-snmp example and using snmptrapd, if I send

snmptrap -v 3 -n “” -a SHA -A mypassword -l authNoPriv -u traptest -e 0x8000000001020304 localhost 0 linkUp.0

everything works. If I send

snmptrap -v 3 -n “” -l noAuthNoPriv -u traptest -e 0x8000000001020304 localhost 0 linkUp.0

the trap is not received by snmptrapd.

Using a similar test with snmp4j, this last test will result in my listener being notified of the trap. My assumption would have been that the USM.processIncomingMessage should have rejected this message. However, in that block of code, the authentication testing is only performed if the client indicated the request was authNoPriv:

  if (((securityLevel >= SecurityLevel.AUTH_NOPRIV) && (auth == null)) ||
      (((securityLevel >= SecurityLevel.AUTH_PRIV) && (priv == null)))) {

This seems to allow the security level to be defined by the sender instead of the receiver.

This behavior does not seem to be correct, but I have to admit that I don’t completely understand the V3 specifications.

Thanks Again!

dm

4

Your assumption is wrong, that the USM has to check whether the security level of the sender matches the maximum possible security level of an USM entry and then reject incoming requests if that is not the case.
That is not the task of the USM. As I have written before, this check is done by the VACM. If you do not use a VACM on top of USM, then you will see the trap in your application.

There NET-SNMP tools are not a good reference for SNMP standard compliance because they implement a lot of “tricks” helping SNMP beginners to get started but that often is different to how SNMP works on the protocol level.

Please keep also in mind, that the trap/notification sender is authoritative (for an INFORM request the receiver is authoritative)!

5

Thanks for the clarification!

dm