The SNMP version 3 (v3) is the third version of the Internet Standard Management Framework and is derived from and builds upon both the original Internet Standard Management Framework SNMP version 1 (v1) and the second Internet Standard Management Framework SNMP version 2 (v2).
The SNMPv3 is not a stand-alone replacement for SNMPv1 or SNMPv2. The SNMPv3 defines security capabilities you must use in conjunction with SNMPv2 (preferred) or SNMPv1. The following figure shows how SNMPv3 specifies a user-based security model (USM) that uses a payload of either an SNMPv1 or an SNMPv2 Protocol Data Unit (PDU).
SNMPv3 is an SNMP framework that supplements SNMPv2 by supporting the following:
New SNMP message formats
Security for messages
Access control
Remote configuration of SNMP parameters
The recipient of a message can use authentication within the USM to verify the message sender and to detect if the message is altered. According to RFC2574, if you use authentication, the USM checks the entire message for integrity.
An SNMP entity is an implementation of this architecture. Each SNMP entity consists of an SNMP engine and one or more associated applications.
An SNMP engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects. A one-to-one association exists between an SNMP engine and the SNMP entity, which contains the SNMP engine.
Within an administrative domain, an EngineID is the unique identifier of an SNMP engine. Because there is a one-to-one association between SNMP engines and SNMP entities, the ID also uniquely and unambiguously identifies the SNMP entity within that administrative domain. The system generates an EngineID during the startup process. The SNMP engine contains a:
Automatic discovery of a Remote EngineID is performed so that Inform messages are populated properly and not rejected by the SNMP Manager. This automatic discovery is performed by the switch using a request to the Manager for a response that contains the EngineID. The switch then uses this Remote EngineID value to populate all subsequent Inform messages.
The dispatcher is part of an SNMP engine. You can use the dispatcher for concurrent support of multiple versions of SNMP messages in the SNMP engine through the following ways:
To send and receive SNMP messages to and from the network.
To determine the SNMP message version and interact with the corresponding message processing model.
To provide an abstract interface to SNMP applications for delivery of a PDU to an application.
To provide an abstract interface for SNMP applications to send a PDU to a remote SNMP entity.
The message processing subsystem prepares messages for sending and extracts data from received messages. The subsystem can contain multiple message processing models.
The security subsystem provides the following features:
Authentication
Privacy
Security
You can use authentication within the SNMPv3 to verify the message sender and whether the message is altered. If you use authentication, the integrity of the message is verified. The supported SNMPv3 authentication protocols are HMAC-MD5 and HMAC-SHA-96. By default, the switch uses HMAC-SHA1-96 with 160-bit key length.
SNMPv3 is an encryption protocol for privacy. Only the data portion of a message is encrypted; the header and the security parameters are not. The privacy protocol that SNMPv3 supports is CBC-DES Symmetric Encryption Protocol and Advanced Encryption Standard (AES).
The SNMPv3 security protects against:
Modification of information—protects against altering information in transit.
Masquerade—protects against an unauthorized entity assuming the identity of an authorized entity.
Message stream modification—protects against delaying or replaying messages.
Disclosure—protects against eavesdropping.
The SNMPv3 security also offers:
Discovery procedure—finds the EngineID of an SNMP entity for a given transport address or transport endpoint address.
Time synchronization procedure—facilitates authenticated communication between entities
The SNMPv3 does not protect against the following:
Denial-of-service—prevention of exchanges between manager and agent.
Traffic analysis—general pattern of traffic between managers and agents.
SNMPv3 provides a group option for access policies.
The access policy feature in the switch determines the access level for the users connecting to the device with different services like File Transfer Protocol (FTP), Trivial FTP (TFTP), and Telnet. The system access policy feature is based on the user access levels and network address. This feature covers services, such as TFTP, HTTP, SSH, and SNMP. However, with the SNMPv3 engine, the community names do not map to an access level. The View-based Access Control Model (VACM) determines the access privileges.
Use the configuration feature to specify groups for the SNMP access policy. You can use the access policy services to cover SNMP. Because the access restriction is based on groups defined through the VACM, the synchronization is made using the SNMPv3 VACM configuration. The administrator uses this feature to create SNMP users (USM community) and associate them to groups. You can configure the access policy for each group and network.
The following are feature specifications for the group options:
After you enable SNMP service, this policy covers all users associated with the groups configured under the access policy. The access privileges are based on access allow or deny. If you select allow, the VACM configuration determines the management information base (MIB)-views for access.
The SNMP service is disabled by default for all access policies.
The access level configured under access-policy policy <id> does not affect SNMP service. The VACM configuration determines the SNMP access rights.
In a USM system, the security model uses a defined set of user identities for any authorized user on a particular SNMP engine. A user with authority on one SNMP engine must also have authorization on all SNMP engines with which the original SNMP engine communicates.
The USM provides the following levels of communication:
NoAuthNoPriv—communication without authentication and privacy.
AuthNoPriv—communication with authentication and without privacy.
AuthPriv—communication with authentication and privacy.
The following figure shows the relationship between USM and VACM.
View-based Access Control Model (VACM) provides group access, group security levels, and context based on a predefined subset of MIB objects. These MIB objects define a set of managed objects and instances.
VACM is the standard access control mechanism for SNMPv3, and it provides:
Authorization service to control access to MIB objects at the PDU level.
Alternative access control subsystems.
The access is based on principal, security level, MIB context, object instance, and type of access requested (read or write). You can use the VACM MIB to define the policy and control remote management.
A user-based security port for SNMPv3 is defined as a security subsystem within an SNMP engine. The switch USM uses HMAC-MD5-96 and HMAC-SHA-96 as the authentication protocols, and CBC-DES as the privacy protocol. Use USM to use other protocols instead of, or concurrently with, these protocols. CFB128-AES-128, an AES-based Symmetric Encryption Protocol, is an alternative privacy protocol for the USM.
The AES standard is the current encryption standard, Federal Information Processing Standard 140-2 (FIPS 140-2), intended to be used by the U.S. Government organizations to protect sensitive information. The AES standard is also becoming a global standard for commercial software and hardware that uses encryption or other security features.
This symmetric encryption protocol provides support for data confidentiality. The system encrypts the designated portion of the SNMP message and includes it as part of the transmitted message.
The USM specifies that the scoped PDU is the portion of the message that requires encryption. An SNMP engine that can legitimately originate messages on behalf of the appropriate user shares a secret value, in combination with a timeliness value and a 64-bit integer, used to create the (localized) encryption/decryption key and the initialization vector.
The AES encryption key uses the first 128 bits of the localized key. The 128-bit Initialization Vector (IV) is the combination of the authoritative SNMP engine 32-bit snmpEngineBoot, the SNMP engine 32-bit snmpEngineTime, and a local 64-bit integer. The system initializes the 64-bit integer to a pseudo-random value at startup time.
The switch handles data encryption in the following manner:
The system treats data as a sequence of octets.
The system divides the plaintext into 128-bit blocks.
The first input block is the IV, and the forward cipher operation is applied to the IV to produce the first output block.
The system produces the first cipher text block by executing an exclusive-OR function on the first plaintext block with the first output block.
The system uses the cipher text block as the input block for the subsequent forward cipher operation.
The system repeats the forward cipher operation with the successive input blocks until it produces a cipher text segment from every plaintext segment.
The system produces the last cipher text block by executing an exclusive-OR function on the last plaintext segment of r bits (r is less than or equal to 128) with the segment of the r most significant bits of the last output block.
The switch handles data decryption in the following manner:
In CFB decryption, the IV is the first input block, the system uses the first cipher text for the second input block, the second cipher text for the third input block, and this continues until the system runs out of blocks to decrypt.
The system applies the forward cipher function to each input block to produce the output blocks.
The system passes the output blocks through an exclusive-OR function with the corresponding cipher text blocks to recover the plaintext blocks.
The system sends the last cipher text block (whose size r is less than or equal to 128) through an exclusive-OR function with the segment of the r most significant bits of the last output block to recover the last plaintext block of r bits.
You configure traps by creating SNMP trap notifications, creating a target address to which you want to send the notifications, and specifying target parameters. For more information about how to configure trap notifications, see Logs and Traps.