SNMP v3 Security Notes

Starting from SNMPv3, an instance of a software implementation of SNMP has come to be known as an SNMP entity, where an SNMP entity consists of a single SNMP engine and one or more associated applications.

Applications may be any or all of the following:

  • Command Responder (a.k.a. Agent and is usually the host of one or more management information base)
  • Command Generator (a.k.a. Manager)
  • Notification Originator
  • Notification Receiver.

In VTScada applications that are meant to publish via SNMP or for some SNMP Agent Polling, look for SNMP Agent Configuration in the Other Tab of the Edit Properties Page. The SNMP version must be set to v3 for all options to be displayed.

The SNMP engine is the core software that receives SNMP requests from remote entities and channels them to the appropriate processors, authenticators, decryptors, and applications. It processes the responses before sending them back to remote entities. The SNMP engine also takes requests from applications, processes, encrypts and authenticates them accordingly, and sends them to remote entities. It also processes the related incoming responses.

Here are some aspects of the SNMP engine that you should be aware of:

The SNMP Engine ID

SNMPv3 requires that an application be able to identify the remote SNMP engine of the remote SNMP entity uniquely, in order to retrieve or manipulate objects maintained on that entity. The SNMP Engine ID (stored as "snmpEngineID" in the management information base at "1.3.6.1.6.3.10.2.1") is a unique identifier of an engine and also of an entity.

An SNMP Context

An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context and an SNMP entity potentially has access to many contexts. A context is identified by the EngineID value of the entity hosting the management information (contextEngineID) and a context name that identifies the specific context (contextName).

The User-based Security Model (USM)

The User-based Security Model (USM) is the most widely used security model in SNMPv3. A USM SNMP packet reserves two fields for the identification of SNMP entities. One field identifies the authoritative entity. The second field identifies the entity hosting the context to which the data belongs. Since EngineID is well defined as an entity unique identifier, it is used by USM. The USM entity's identification fields are further explained here:

  • authoritativeEngineID
    The rules for designating the authoritative engine are as follows: if the SNMP message requires a response (get, getnext, getbulk, set, or inform), the receiver of these messages is authoritative. If the message does not require a response (trap or report), the sender of the message is authoritative. Generally, an SNMP agent is authoritative, and a manager is nonauthoritative. A nonauthoritative engine must discover the snmpEngineId of the authoritative engine with which it communicates. USM describes a mechanism for authoritative EngineID discovery in RFC3414.
  • contextEngineID:
    This is the EngineID of the entity that hosts the context to which the data belongs. For simplicity and for most practical purposes authoritativeEngineID and contextEngineID are the same.

Special consideration for user credentials

VTScada has a single SNMP engine in every application and the corresponding EngineID is unique for every [workstation + application] pair. This engine serves the single SNMP Agent as well as all the SNMP driver tags running in the application. VTScada’s SNMP engine supports and services the USM authoritative engineID discovery mechanism.

Because each VTScada application has a single SNMP engine, all SNMP Driver tags (and the SNMP Agent if enabled) in that application share the same local SNMP engine identity. This is important to know when configuring any SNMPv3 username and credentials.

Here is one example of how conflicting credentials can clash:

SNMPv3 Informs received by VTScada-- the VTScada application is the authoritative engine because the Inform message requires a response; The USM user credentials used to authenticate and decrypt incoming Informs are associated with VTScada’s local authoritative engine. In the USM users database, these users belong under the local engine’s entry, not under the remote device’s engine entry.

Inform credentials are not independent per SNMP Driver tag when the same username is used. If two SNMP Driver tags in the same VTScada application are configured to receive Informs using the same SNMPv3 username but with different authentication passwords, privacy passwords, authentication protocols, or privacy protocols, the definitions conflict because they refer to the same user under the same local authoritative engine.

For example, suppose one VTScada application contains two SNMP Driver tags:

Driver: Inform username: Inform credentials:
SNMPDrvr1 John Smith PWD1
SNMPDrvr2 John Smith PWD2

 

Both drivers attempt to register the same USM user, John Smith, under the VTScada application’s local SNMP engine. The first registration succeeds. The second registration fails because the same username already exists for the same authoritative engine but with different credentials. The affected driver will report a relevant configuration error and will not operate normally until the conflict is corrected.

To avoid this conflict, use one of the following approaches:

  1. Use the same SNMPv3 credentials for the same Inform username across all SNMP Driver tags in the same VTScada application.
  2. Use different Inform user names in different drivers when different passwords or security protocols are required.

Because each VTScada application has a single SNMP engine, all SNMP Driver tags (and the single SNMP Agent if enabled) in that application share the same local SNMP engine identity.

When the local engine is authoritative, all the following credentials fall under the LocalEngineID entry in the USM and hence ALL may clash with each other:

  • For all SNMP drivers in the app - Informs credentials.
  • For the single SNMP Agent in the app if enabled- Read Only user credentials, Read/Write user credentials, outgoing Traps username credentials

For example, credentials for Traps outgoing from our SNMP Agent may clash with credentials for Informs incoming to one or more of our SNMP drivers.

When the remote engine is authoritative, all the following credentials fall under the RemoteEngineID entry in the USM and hence ALL may clash with each other:

  • For all SNMP drivers connected to the remote engine in the app - remote read or read/write user entered in the "Agent" config tab of a driver, incoming Traps user entered in the "Traps" config tab of a driver.
  • For the single SNMP Agent in the app if enabled - Outgoing Informs that the user has entered in the credentials tab of the SNMP Agent Destination tag connected to the remote engine.