rfc1351.txt

<VC++网络游戏建摸与实现>源代码

   knowledge of private keys is not normally afforded to human beings
   and is confined to those portions of the protocol implementation that
   require it.

   Although all SNMP agents that use cryptographic keys in their
   communication with other protocol entities will almost certainly
   engage in private SNMP exchanges to distribute those keys, in order
   to simplify this example, neither the management station nor the
   proxy agent sends or receives private SNMP communications. Thus, the
   privacy protocol for each of them is recorded as noPriv.

   The party curly does not send or receive SNMP protocol messages;
   rather, all communication with that party proceeds via a hypothetical
   proprietary protocol identified by the value acmeMgmtPrtcl. Because
   the party curly does not participate in the SNMP, many of the
   attributes recorded for that party in a local database are ignored.

   In order to interrogate the proprietary device associated with the
   party curly, the management station larry constructs a SNMP GetNext
   request and transmits it to the party moe operating (see Table 7) at
   UDP port 161, and IP address 1.2.3.5. This request is authenticated
   using the private authentication key "0123456789ABCDEF."



Davin, Galvin, & McCloghrie                                    [Page 23]

RFC 1351               SNMP Administrative Model               July 1992


   When that request is received by the party moe, the originator of the
   message is verified as being the party larry by using local knowledge
   (see Table 6) of the private authentication key "0123456789ABCDEF."
   Because party larry is authorized to issue GetNext requests with
   respect to party moe by the relevant access control policy (Table 8),
   the request is accepted. Because the local database records the
   proxied party for party moe as curly, the request is satisfied by its
   translation into appropriate operations of the acmeMgmtPrtcl directed
   at party curly. These new operations are transmitted to the party
   curly at the address 0x98765432 in the acmeMgmtPrtcl domain.

   When and if the proprietary protocol exchange between the proxy agent
   and the proprietary device concludes, a SNMP GetResponse management
   operation is constructed by the SNMP party moe to relay the results
   to party larry. This response communication is authenticated as to
   origin and integrity using the authentication protocol
   md5AuthProtocol and private authentication key "GHIJKL0123456789"
   specified for transmissions from party moe. It is then transmitted to
   the SNMP party larry operating at the management station at IP
   address 1.2.3.4 and UDP port 2002 (the source address for the
   corresponding request).

   When this response is received by the party larry, the originator of
   the message is verified as being the party moe by using local
   knowledge (see Table 7) of the private authentication key
   "GHIJKL0123456789." Because party moe is authorized to issue
   GetResponse communications with respect to party larry by the
   relevant access control policy (Table 8), the response is accepted,
   and the interrogation of the proprietary device is complete.

   It is especially useful to observe that the database of SNMP parties
   recorded at the proxy agent (Table 6) need be neither static nor
   configured exclusively by the management station.  For instance,
   suppose that, in this example, the acmeMgmtPrtcl was a proprietary,
   MAC-layer mechanism for managing stations attached to a local area
   network. In such an environment, the SNMP party moe would reside at a
   SNMP proxy agent attached to such a LAN and could, by participating
   in the LAN protocols, detect the attachment and disconnection of
   various stations on the LAN. In this scenario, the SNMP proxy agent
   could easily adjust its local database of SNMP parties to support
   indirect management of the LAN stations by the SNMP management
   station. For each new LAN station detected, the SNMP proxy agent
   would add to its database both an entry analogous to that for party
   curly (representing the new LAN station itself) and an entry
   analogous to that for party moe (representing a proxy for that new
   station in the SNMP domain).

   By using the SNMP to interrogate the database of parties held locally



Davin, Galvin, & McCloghrie                                    [Page 24]

RFC 1351               SNMP Administrative Model               July 1992


   by the SNMP proxy agent, a SNMP management station can discover and
   interact with new stations as they are attached to the LAN.

4.3.2   Native Proxy Configuration

   This section presents an example configuration that supports SNMP
   native proxy operations -- indirect interaction between a SNMP agent
   and a management station that is mediated by a second SNMP (proxy)
   agent.

   This example configuration is similar to that presented in the
   discussion of SNMP foreign proxy above. In this example, however, the
   party associated with the identity curly receives messages via the
   SNMP, and, accordingly interacts with the SNMP proxy agent moe using
   authenticated SNMP communications.

   Table 9 presents information about SNMP parties that is recorded in
   the local database of the SNMP proxy agent.  Table 7 presents
   information about SNMP parties that is recorded in the local database
   of the SNMP management station. Table 10 presents information about
   the access policy specified by the local administration.

   As represented in Table 9, the proxy party operates at UDP port 161
   at IP address 1.2.3.5 using the party identity moe;

  Identity       larry              moe                curly
                 (manager)          (proxy)            (proxied)
  Domain         rfc1351Domain      rfc1351Domain      rfc1351Domain
  Address        1.2.3.4, 2002      1.2.3.5, 161       1.2.3.6, 16
  Proxied Party  noProxy            curly              noProxy
  Auth Prot      md5AuthProtocol    md5AuthProtocol    md5AuthProtocol
  Auth Priv Key  "0123456789ABCDEF" "GHIJKL0123456789" "MNOPQR0123456789"
  Auth Pub Key   ""                 ""                 ""
  Auth Clock     0                  0                  0
  Auth Last Msg  0                  0                  0
  Auth Lifetime  500                500                500
  Priv Prot      noPriv             noPriv             noPriv
  Priv Priv Key  ""                 ""                 ""
  Priv Pub Key   ""                 ""                 ""

         Table 9: Party Information for Proxy Agent










Davin, Galvin, & McCloghrie                                    [Page 25]

RFC 1351               SNMP Administrative Model               July 1992


               Target   Subject   Privileges
               moe      larry     3
               larry    moe       20
               curly    moe       3
               moe      curly     20

         Table 10: Access Information for Native Proxy

   the example manager operates at UDP port 2002 at IP address 1.2.3.4
   using the identity larry; the proxied party operates at UDP port 161
   at IP address 1.2.3.6 using the party identity curly. Messages
   generated by all three SNMP parties are authenticated as to origin
   and integrity by using the authentication protocol md5AuthProtocol
   and distinct, private authentication keys. Although these private key
   values ("0123456789ABCDEF," "GHIJKL0123456789," and
   "MNOPQR0123456789") 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 order to interrogate the proxied device associated with the party
   curly, the management station larry constructs a SNMP GetNext request
   and transmits it to the party moe operating (see Table 7) at UDP port
   161 and IP address 1.2.3.5. This request is authenticated using the
   private authentication key "0123456789ABCDEF."

   When that request is received by the party moe, the originator of the
   message is verified as being the party larry by using local knowledge
   (see Table 9) of the private authentication key "0123456789ABCDEF."
   Because party larry is authorized to issue GetNext (and Get) requests
   with respect to party moe by the relevant access control policy
   (Table 10), the request is accepted. Because the local database
   records the proxied party for party moe as curly, the request is
   satisfied by its translation into a corresponding SNMP GetNext
   request directed from party moe to party curly. This new
   communication is authenticated using the private authentication key
   "GHIJKL0123456789" and transmitted to party curly at the IP address
   1.2.3.6.

   When this new request is received by the party curly, the originator
   of the message is verified as being the party moe by using local
   knowledge (see Table 9) of the private authentication key
   "GHIJKL0123456789." Because party moe is authorized to issue GetNext
   (and Get) requests with respect to party curly by the relevant access
   control policy (Table 10), the request is accepted. Because the local
   database records the proxied party for party curly as noProxy, the
   GetNext request is satisfied by local mechanisms. A SNMP GetResponse
   message representing the results of the query is then generated by



Davin, Galvin, & McCloghrie                                    [Page 26]

RFC 1351               SNMP Administrative Model               July 1992


   party curly. This response communication is authenticated as to
   origin and integrity using the private authentication key
   "MNOPQR0123456789" and transmitted to party moe at IP address 1.2.3.5
   (the source address for the corresponding request).

   When this response is received by party moe, the originator of the
   message is verified as being the party curly by using local knowledge
   (see Table 9) of the private authentication key "MNOPQR0123456789."
   Because party curly is authorized to issue GetResponse communications
   with respect to party moe by the relevant access control policy
   (Table 10), the response is not rejected. Instead, it is translated
   into a response to the original GetNext request from party larry.
   This response is authenticated as to origin and integrity using the
   private authentication key "GHIJKL0123456789" and is transmitted to
   the party larry at IP address 1.2.3.4 (the source address for the
   original request).

   When this response is received by the party larry, the originator of
   the message is verified as being the party moe by using local
   knowledge (see Table 7) of the private authentication key
   "GHIJKL0123456789." Because party moe is authorized to issue
   GetResponse communications with respect to party larry by the
   relevant access control policy (Table 10), the response is accepted,
   and the interrogation is complete.

4.4   Public Key Configuration

   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.
















Davin, Galvin, & McCloghrie                                    [Page 27]

RFC 1351               SNMP Administrative Model               July 1992


    Identity          ollie                      stan
                      (agent)                    (manager)
    Domain            rfc1351Domain              rfc1351Domain
    Address           1.2.3.4, 161               1.2.3.5, 2004
    Proxied Party     noProxy                    noProxy
    Auth Prot         pkAuthProtocol             pkAuthProtocol
    Auth Priv Key     "0123456789ABCDEF"         ""
    Auth Pub Key      ""                         "ghijkl0123456789"
    Auth Clock        0                          0
    Auth Last Msg     0                          0
    Auth Lifetime     500                        500
    Priv Prot         noPriv                     noPriv
    Priv Priv Key     ""                         ""
    Priv Pub Key      ""                         ""

       Table 11: Party Information for Public Key Agent

   The example configuration comprises a single SNMP agent that
   interacts with a single SNMP management station.  Tables 11 and 12
   present information about SNMP 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.

   As represented in Table 11, 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
   SNMP authentication protocol pkAuthProtocol and their distinct,
   private

    Identity          ollie                  stan
                      (agent)                (manager)
    Domain            rfc1351Domain          rfc1351Domain
    Address           1.2.3.4, 161           1.2.3.5, 2004
    Proxied Party     noProxy                noProxy
    Auth Prot         pkAuthProtocol         pkAuthProtocol
    Auth Priv Key     ""                     "GHIJKL0123456789"
    Auth Pub Key      "0123456789abcdef"     ""
    Auth Clock        0                      0
    Auth Last Msg     0                      0
    Auth Lifetime     500                    500
    Priv Prot         noPriv                 noPriv
    Priv Priv Key     ""                     ""
    Priv Pub Key      ""                     ""

   Table 12:  Party Information for Public Key Management
              Station



Davin, Galvin, & McCloghrie                                    [Page 28]

RFC 1351               SNMP Administrative Model               July 1992


   authentication keys. Although these private authentication key values
   ("0123456789ABCDEF" and "GHIJKL0123456789") are presented here for
   expository purposes, knowledge of private