JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Solaris System Management Agent Administration Guide
search filter icon
search icon

Document Information


1.  Introduction to the System Management Agent

2.  Configuring the System Management Agent

3.  Working with the System Management Agent

4.  Managing Security

Security Overview

Using USM for Authentication and Message Privacy

Authentication Protocol Algorithms

Message Privacy

Public Keys

Where USM Security Information Is Contained

Using VACM for Access Control

Where VACM Security Information Is Contained

Understanding VACM Tables

Context Table

Security to Group Table

View Tree Family Table

Access Table

Troubleshooting Problems With VACM Tables

Creating and Managing Users

To Create a New SNMPv3 User

To Create a New User Using System Prompts

To Create Additional SNMPv3 Users With Security

Managing SNMPv1 and SNMPv2c Users With SNMPv3 Security

Proxy Statements and Security

Creating and Managing Groups

5.  Migrating From Other Agents

A.  Tools and Man Pages



Using USM for Authentication and Message Privacy

The User-based Security Model (USM) is used by the System Management Agent for authentication, encryption, and decryption of SNMPv3 packets. USM is used for the following reasons:

The snmpusm utility is an SNMP application for basic maintenance of an SNMP agent's USM table. You must have write access to the usmUserTable MIB table. For more information, see the snmpusm(1M) man page.

Note - The snmpusm subcommands are not supported for v1 or v2c versions of SNMP. Without proxying, only SNMPv3 users can execute these commands.

The agent enables you to manage user entries through the main snmpd.conf configuration file and by use of the snmpusm command, through the USM MIB. The USM MIB enables the System Management Agent to find information about the user, including whether the user exists. Every request from a user is checked against the USM MIB. If the user exists, the USM MIB checks the following permissions:

The USM MIB uses the local store key to compute a new digest that is based upon the authentication protocol specified by a particular user in the MIB. The computed digest is compared to the digest saved from the incoming packet. If the digests are the same, the user is authenticated. For more information on message digests, see Authentication Protocol Algorithms.

The following list describes the USM settings:


Identifies the user that is authorized to communicate with the SNMP engine.

Authorization Type

Specifies the authentication protocol algorithm to be used: MD5 and SHA. For more information, see Authentication Protocol Algorithms.

Authorization Password

Specifies the user's authentication password. Passwords must consist of at least eight characters.

Privacy Type:

Specifies the privacy protocol to be used. For the System Management Agent, the privacy protocol is DES (Data Encryption Standard). For more information, see Message Privacy.

Privacy Password:

Specifies the user's privacy password. Passwords must consist of at least eight characters.

Security Level:

Indicates the security level of the user with regard to authentication and privacy:


Uses just the user name match for authentication.


Provides authentication that is based on the MD5 or SHA1 algorithm.


Provides privacy (encryption) based on the DES protocol.

Authentication uses a secret key to generate a MAC (Message Authentication Code) stored in msgAuthenticationParameters, which is part of usmSecurityParameters. Both the sending and receiving entities use the same secret key to produce the MAC. The message is therefore authenticated if both the sending and receiving MACs match.

Authentication Protocol Algorithms

In USM as implemented by the System Management Agent, two authentication protocols are supported. These authentication protocols are described in the following list.


In the System Management Agent, the Message Digest implementation is HMAC-MD5–96. Based on MD5, this one-way encryption uses a 96–bit hash a 16 octet key length. Computationally, no two messages can have the same message digest. Also you cannot produce a message from a given prespecified target message digest. The MD5 algorithm is designed for digital signature applications. In these applications, large files must be securely compressed before being encrypted with a private key under a public-key cryptosystem. The HMAC-MD5–96 algorithm can be used with 32-bit machines. No large substitution tables are required. The algorithm can be coded quite compactly. For more information on MD5, see RFC 1321 at


In the System Management Agent, the Secure Hash Algorithm (SHA) implementation is HMAC-SHA–96. This one-way encryption uses a 96–bit hash and a 20–octet key length. The algorithm takes as input a message of less than 264 bits in length. The input message is processed in 512–bit blocks. The algorithm produces a 160-bit message digest output. This message digest can then, for example, be used as an input to a signature algorithm, which generates or verifies the signature for the message. The message digest is signed, instead of the message itself, which improves efficiency because the message digest is smaller than the original message. If the creator of a digital signature uses SHA, then the verifier of the digital signature clearly must also use SHA. If the message is changed during transit, this change almost always changes the message digest, so the digital signature fails to verify. SHA is secure because computationally no two messages can have the same message digest. You also cannot produce a message from a given prespecified target message digest. The design of SHA is similar to the MD5 family of hash functions. For more information on SHA, see RFC 3174 at

For the System Management Agent, the default authentication protocol is HMAC-MD5–96. Setting is auth proto = MD5.

Message Privacy

USM supports privacy of messages. USM uses the CBC-DES Symmetric Encryption Protocol for encrypting and decrypting SNMPv3 packets. In the same way as with authentication, the same secret privacy key is used to encrypt and decrypt messages on both sides. Only the data portion is encrypted. The auth flag must be enabled and the security level must have privacy enabled to use encryption. Only the scopedPDU is encrypted. For more information, see Where USM Security Information Is Contained.

Currently, DES encryption is supported on the Solaris OS. DES encryption uses 56–bit key encryption. This level is the highest encryption level currently supported for DES, in this release of the Solaris software.

Public Keys

The System Management Agent supports Public Key Cryptography Standard (PKCS) #11. This token interface standard defines the interface that is used for communication between SSL and PKCS #11 modules. The version of PKCS on which the PKCS library compiled with the System Management Agent is based is the PKCS#11 v2.11 standard.

As described in Authentication Protocol Algorithms, the SHA1 algorithm is supported in addition to MD5. If the PKCS library is not found on your system, then the SMA attempts to use the standard Net-SNMP internal MD5, without DES support.

Where USM Security Information Is Contained

In an SNMPv3 packet string, USM information is contained in the following flags:


A single octet to indicate how the message is to be processed. For example, two bits of the msgFlags octet specify whether the packet has been encrypted and whether the packet has been authenticated. This flag is used to determine the security level of the message. Security levels, which are indicated in the main snmpd.conf file, are as follows:


Represented by an integer: 1.

Least access.


Represented by an integer: 2.

More access than noAuthNoPriv but lower than authPriv.


Represented by an integer: 3.

Most access, most secure.


Specifies the security model used to generate the message, enabling the receiving entity to employ the appropriate model for security processing. In the System Management Agent, USM is the only supported security model.


An octet string containing data about the security model. This data is defined by the security model or models you are using. This data is used only by the security model or models you are using. The security model or models are specified in msgSecurityModel. USM uses this field to authenticate, encrypt, and decrypt SNMPv3 messages.


Contains the normal Protocol Data Unit (PDU) and information for identifying the administratively unique context for processing the PDU. SNMPv2 and SNMPv3 messages both use the same PDU format. This scopedPDU format is encrypted if privacy was enabled for the transaction.

The MIB definitions for USM can be found at /etc/sma/snmp/mibs/SNMP-USER-BASED-SM-MIB.txt.

For more information about USM, see RFC 3414 at