Explanation about SNMPv3 USM

Question

Context

I am having trouble understanding the USM model in SNMPv3. I base my research and understanding on RFC 3414.

My problem is that authentication is not enforced in some implementations of SNMP, and in my opinion, this breaks the entire security model.

Question

The use case is :

Sending a SNMPv3 TRAP with noAuthNoPriv to a trap receiver where the configured USM model is authPriv must accept or denies the received TRAP.

The implementation on witch I am working accept the TRAP, and I think that the TRAP must be refused. Who is right ?

My research In the RFC 3414 section 3.2 Processing an Incoming SNMP Message

the text say :

This section describes the procedure followed by an SNMP engine
whenever it receives a message containing a management operation on
behalf of a user, with a particular securityLevel.

.. text omitted until step 5

5. If the information about the user indicates that it does not support the securityLevel requested by the caller, then the usmStatsUnsupportedSecLevels counter is incremented and an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module.

6. If the securityLevel specifies that the message is to be authenticated, then the message is authenticated according to the user's authentication protocol. To do so a call is made to the authentication module that implements the user's authentication protocol according to the abstract service primitive:

I understand 2 principles in this text :

1. From step 5 -> The USM must support the level send by the TRAP and for me support means equals.
2. From step 6 -> The authentication must success

My feeling

When I set up authentication on both the client and the server, I expect dual authentication (client-server), or at least that messages sent by the client are authenticated. If I'm wrong and the system has to accept this trap, it means that anyone can send an SNMPv3 TRAP on behalf of anyone.

Setting this security parameter gives a false sense of security and only an SNMPv3 expert will be able to understand its error. This is in my opinion a bad choice, which probably creates a lot of security holes in multiple places.

Side note INFORM message

I have heard that I need to use INFORM instead of TRAP for have fully authenticated message. But this is not my question I really wanna to understand the USM model.

Side note I hope I am right, because otherwise, I have the feeling that the USM RFC SNMPv3 is badly written (not that I can do better), because setting security parameters who can be ignored, give a false security feeling.

When I set an authentiation in both client + server, I think there is a double authentication. If I am wrong there is not, and can send easily TRAP on the behalf on an another system.

Note: I know there is VACM, but I am focussing onlyonly on the usage of USM from the according RFC. I want to understand the meaning and usage of USM not other way to perform the same task.

Answer 1

Disclaimer I am not expert so take the following with precautions.

In SNMPv3, the USM is responsible to validate only on the SNMP authoritative engine, this engine depending of the kind of message.

• Agent : GET / SET / TRAP
• Receiver : INFORM

The RFC 3414 describe the receive of message in section 3.2 :

5. If the information about the user indicates that it does not support the securityLevel requested by the caller, then the usmStatsUnsupportedSecLevels counter is incremented and an error indication (unsupportedSecurityLevel) together with the OID and value of the incremented counter is returned to the calling module.

6)If the securityLevel specifies that the message is to be authenticated, then the message is authenticated according to the user’s authentication protocol. To do so a call is made to the authentication module that implements the user’s authentication protocol according to the abstract service primitive

The important point is the non authoritative SNMP engine didn't have a security model. So in the step 6, the securitfyLevel is the one from the message. This means the TRAP is accepted by the USM layer even if the authentication is not provided.

This is then the task of user of the TRAP to choice if the message must be interpreted. Generally speaking the PDU or the object containing the information kept the security level in memory and it's the user task to check it.