This section presents an example configuration predicated upon a hypothetical security protocol. This hypothetical protocol would be based on asymmetric (public key) cryptography as a means for providing data origin authentication (but not protection against disclosure). This example illustrates the consistency of the administrative model with public key technology, and the extension of the example to support protection against disclosure should be apparent.
Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2004 Auth Prot pkAuthProtocol pkAuthProtocol Auth Priv Key "0123456789ABCDEF" "" Auth Pub Key "0123456789abcdef" "ghijkl0123456789" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 16: Party Information for Public Key Agent
The example configuration comprises a single SNMPv2 agent that interacts with a single SNMPv2 management station. Tables 16 and 17 present information about SNMPv2 parties that is by the agent and manager, respectively, while Table 5 presents information about the local access policy that is known to both manager and agent.
Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2004 Auth Prot pkAuthProtocol pkAuthProtocol Auth Priv Key "" "GHIJKL0123456789" Auth Pub Key "0123456789abcdef" "ghijkl0123456789" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 17: Party Information for Public Key Management Station
As represented in Table 16, the example agent party operates at UDP port 161 at IP address 1.2.3.4 using the party identity ollie; the example manager operates at UDP port 2004 at IP address 1.2.3.5 using the identity stan. Both ollie and stan authenticate all messages that they generate as to origin and integrity by using the hypothetical SNMPv2 authentication protocol pkAuthProtocol and their distinct, private authentication keys. Although these private authentication key values ("0123456789ABCDEF" and "GHIJKL0123456789") are presented here for expository purposes, knowledge of private keys is not normally afforded to human beings and is confined to those portions of the protocol implementation that require it.
In most respects, the interaction between manager and agent in this configuration is almost identical to that in the example of the minimal, secure SNMPv2 agent described above. The most significant difference is that neither SNMPv2 party in the public key configuration has knowledge of the private key by which the other party authenticates its transmissions. Instead, for each received authenticated SNMPv2 communication, the identity of the originator is verified by applying an asymmetric cryptographic algorithm to the received message together with the public authentication key for the originating party. Thus, in this configuration, the agent knows the manager's public key ("ghijkl0123456789") but not its private key ("GHIJKL0123456789"); similarly, the manager knows the agent's public key ("0123456789abcdef") but not its private key ("0123456789ABCDEF").