This section presents an example configuration for a secure, minimal SNMPv2 agent that interacts with a single SNMPv2 management station. Table 4 presents information about SNMPv2 parties that is known both to the minimal agent and to the manager, while Table 5 presents similarly common information about the local access policy.
The interaction of manager and agent in this configuration is very similar to that sketched above for the non-secure minimal agent - except that all protocol messages are authenticated as to origin and integrity and protected from disclosure. This example requires encryption in order to support distribution of secret keys via the SNMPv2 itself. A more elaborate example comprising an additional pair of SNMPv2 parties could support the exchange of non-secret information in authenticated messages without incurring the cost of encryption.
An actual secure agent configuration may require SNMPv2 parties for which the authentication and privacy protocols are noAuth and noPriv, respectively, in order to support clock synchronization (see ). For clarity, these additional parties are not represented in this example.
Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 220.127.116.11, 161 18.104.22.168, 2001 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" Auth Pub Key "" "" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot desPrivProtocol desPrivProtocol Priv Priv Key "MNOPQR0123456789" "STUVWX0123456789" Priv Pub Key "" "" Table 4: Party Information for Secure Minimal Agent Target Subject Context Privileges ollie stan local 35 (Get, GetNext & GetBulk) stan ollie local 132 (Response & SNMPv2-Trap) Table 5: Access Information for Secure Minimal Agent
As represented in Table 4, the example agent party operates at UDP port 161 at IP address 22.214.171.124 using the party identity ollie; the example manager operates at UDP port 2001 at IP address 126.96.36.199 using the identity stan. At minimum, a secure SNMPv2 agent implementation must provide for administrative configuration (and non-volatile storage) of relevant information about two SNMPv2 parties: itself and a remote peer. Both ollie and stan authenticate all messages that they generate by using the SNMPv2 authentication protocol v2md5AuthProtocol and their distinct, private authentication keys. Although these private authentication key values ("0123456789ABCDEF" and "GHIJKL0123456789") are presented here for expository purposes, knowledge of private authentication keys is not normally afforded to human beings and is confined to those portions of the protocol implementation that require it.
When using the v2md5AuthProtocol, the public authentication key for each SNMPv2 party is never used in authentication and verification of SNMPv2 exchanges. Also, because the v2md5AuthProtocol is symmetric in character, the private authentication key for each party must be known to another SNMPv2 party with which authenticated communication is desired. In contrast, asymmetric (public key) authentication protocols would not depend upon sharing of a private key for their operation.
All protocol messages generated for transmission to the party stan are encrypted using the desPrivProtocol privacy protocol and the private key "STUVWX0123456789"; they are decrypted upon reception according to the same protocol and key. Similarly, all messages generated for transmission to the party ollie are encrypted using the desPrivProtocol protocol and private privacy key "MNOPQR0123456789"; they are correspondingly decrypted on reception. As with authentication keys, knowledge of private privacy keys is not normally afforded to human beings and is confined to those portions of the protocol implementation that require it.