|
Due to lack of security with the use of SNMP, network administrators were using other means, such as telnet for configuration, accounting, and fault management. SNMPv3 addresses issues related to the large-scale deployment of SNMP, accounting, and fault management. Currently, SNMP is predominantly used for monitoring and performance management. SNMPv3 defines a secure version of SNMP and also facilitates remote configuration of the SNMP entities.
Primary Goals of SNMPv3
To verify that each received SNMP message has not been modified during its transmission through the network.
To verify the identity of the user on whose behalf a received message claims to have been generated.
To detect received messages that contain management information, whose time of generation was not recent.
To assure that the contents of each received message are protected from disclosure.
Comparative Overview of SNMPv3 with SNMPv1 and SNMPv2c
SNMPv1 and SNMPv2c have a wide deployment base covering the following.
A platform-independent data definition syntax - A subset of ASN.1
A platform-independent data transfer notation - BER
Communication between the peer entities - SNMP communication protocol with message formats, message types, etc.
Message contains the SNMP version
Message contains the community string which is used to provide some security
Guidelines for definition of management data - SMI
Management data definition repository - The MIB files
SNMPv3 provides a secure environment for the management of systems covering the following.
Identification of SNMP entities to facilitate communication only between known SNMP entities - Each SNMP entity has an identifier called the SNMPEngineID, and SNMP communication is possible only if an SNMP entity knows the identity of its peer. Traps and Notifications are exceptions to this rule.
Support for security models - A security model may define the security policy within an administrative domain or an intranet. SNMPv3 contains the specifications for USM.
Definition of security goals where the goals of message authentication service include protection against the following.
Modification of Information - Protection against some unauthorized SNMP entity altering in-transit messages generated by an authorized principal.
Masquerade - Protection against attempting management operations not authorized for some principal by assuming the identity of another principal that has the appropriate authorizations.
Message Stream Modification - Protection against messages getting maliciously re-ordered, delayed, or replayed to effect unauthorized management operations.
Disclosure - Protection against eavesdropping on the exchanges between SNMP engines.
Specification for USM - USM consists of the general definition of the following communication mechanisms available.
Communication without authentication and privacy (NoAuthNoPriv).
Communication with authentication and without privacy (AuthNoPriv).
Communication with authentication and privacy (AuthPriv).
Definition of different authentication and privacy protocols - Currently, the MD5 and SHA authentication protocols and the CBC_DES and CFB_AES_128 privacy protocols are supported in the USM.
Definition of a discovery procedure - To find the SNMPEngineID of an SNMP entity for a given transport address and transport endpoint address.
Definition of the time synchronization procedure - To facilitate authenticated communication between the SNMP entities.
Definition of the SNMP framework MIB - To facilitate remote configuration and administration of the SNMP entity.
Definition of the USM MIBs - To facilitate remote configuration and administration of the security module.
Definition of the VACM MIBs - To facilitate remote configuration and administration of the access control module.
The SNMPv3 focuses on two main aspects, namely security and administration. The security aspect is addressed by offering both strong authentication and data encryption for privacy. The administration aspect is focused on two parts, namely notification originators and proxy forwarders.
SNMPv3 defines two security-related capabilities, namely the USM and VACM. USM provides authentication and privacy (encryption) functions and operates at the message level. VACM determines whether a given principal is allowed access to a particular MIB object to perform specific functions and operates at the PDU level.
The SNMPv3 message consists of the following fields.
msgVersion - This field contains the SNMP message version. A value 0 is an SNMPv1 message, 1 is an SNMPv2c message, 2 is an SNMPv2 message, and 3 is an SNMPv3 message. The value of message version is used to choose between the different message processing models (SNMPv1, SNMPv2c, or SNMPv3) available in the SNMP engine/entity.
The following fields are part of the SNMPv3 message and are not available in the SNMPv1 or SNMPv2c message.
msgID - This field contains the SNMP message identifier. This is the unique ID associated with the message. The msgID field is different from the reqID field available in the PDU. It is possible that a received PDU that is part of a message cannot be decoded due to security parameters between the SNMP entities. The msgID is used to relate the request with a response during a transaction.
msgMaxSize - This field gives the maximum size of the message which the requesting SNMP entity can accept.
msgFlags - This field contains the message security level. The bit 0 of msgFlags indicates whether a message is authenticated. The bit 1 indicates whether a message uses privacy. The bit 2 indicates whether a report PDU is expected for the message (in case the message is dropped or a response cannot be generated).
msgSecurityModel - This field indicates the security model used to generate the message. It has a value of 3 when USM is used.
msgEngineID - This field has the SNMPEngineID of the authoritative SNMP entity involved in the transaction. When a request PDU is generated from an SNMP engine, the remote peer (agent for Get request and manager for Trap request) is the authoritative SNMP entity.
msgEngineBoots - This field indicates the number of times the authoritative SNMP entity has booted. This field is used in authenticated message to validate the timeliness of a message.
msgEngineTime - This field indicates the time since the authoritative SNMP entity has been rebooted. This field is used in authenticated messages to validate the timeliness of a message.
msgUserName - This field contains the principal who originated the request. The fields msgUserName and the msgEngineID are used to locate the security data associated with the message from the USM database. This security data is used to authenticate and process the message.
msgSecurityParams - This field contains the security parameters that are security model dependent. It contains the authentication parameters and the privacy parameters for USM. For an AuthPriv message, the authentication parameter has the digest computed for the message using the authentication protocol applicable for the USM entry and the privacy parameter has the salt generated, while encrypting the message using the privacy protocol applicable to the USM entry.
contextEngineID - Within an administrative domain, the contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName.
contextName - A contextName is used to name a context. Each contextName must be unique within an SNMP entity.
PDU - The SNMP PDU (Protocol Data Unit) is used for communication between the SNMP entities. PDU encapsulates the SNMP request ID, error status, variable bindings, and so on. There are different types of PDUs, such as GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, Trap-PDU, InformRequest-PDU, SNMPv2-Trap-PDU, and Report-PDU. The exact format of the PDU depends on the type of the PDU.
|