rfc1351.txt

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

Network Working Group                                          J. Davin
Request for Comments: 1351          MIT Laboratory for Computer Science
                                                              J. Galvin
                                      Trusted Information Systems, Inc.
                                                          K. McCloghrie
                                               Hughes LAN Systems, Inc.
                                                              July 1992


                       SNMP Administrative Model

Status of this Memo

   This document specifies an IAB standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements. Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol. Distribution of this memo is unlimited.

Table of Contents

   1.    Abstract  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.    Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
   3.    Elements of the Model . . . . . . . . . . . . . . . . . . .  2
   3.1   SNMP Party  . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.2   SNMP Protocol Entity  . . . . . . . . . . . . . . . . . . .  6
   3.3   SNMP Management Station . . . . . . . . . . . . . . . . . .  6
   3.4   SNMP Agent  . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.5   View Subtree  . . . . . . . . . . . . . . . . . . . . . . .  7
   3.6   MIB View  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.7   SNMP Management Communication . . . . . . . . . . . . . . .  8
   3.8   SNMP Authenticated Management Communication . . . . . . . .  9
   3.9   SNMP Private Management Communication   . . . . . . . . . .  9
   3.10  SNMP Management Communication Class . . . . . . . . . . . . 10
   3.11  SNMP Access Control Policy  . . . . . . . . . . . . . . . . 11
   3.12  SNMP Proxy Party  . . . . . . . . . . . . . . . . . . . . . 12
   3.13  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . 13
   3.13.1  Generating a Request  . . . . . . . . . . . . . . . . . . 13
   3.13.2  Processing a Received Communication . . . . . . . . . . . 15
   3.13.3  Generating a Response . . . . . . . . . . . . . . . . . . 17
   4.    Application of the Model  . . . . . . . . . . . . . . . . . 17
   4.1   Non-Secure Minimal Agent Configuration  . . . . . . . . . . 17
   4.2   Secure Minimal Agent Configuration  . . . . . . . . . . . . 20
   4.3   Proxy Configuration   . . . . . . . . . . . . . . . . . . . 21
   4.3.1   Foreign Proxy Configuration . . . . . . . . . . . . . . . 22
   4.3.2   Native Proxy Configuration  . . . . . . . . . . . . . . . 25
   4.4   Public Key Configuration  . . . . . . . . . . . . . . . . . 27
   4.5   MIB View Configurations . . . . . . . . . . . . . . . . . . 29



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


   5.    Compatibility . . . . . . . . . . . . . . . . . . . . . . . 33
   6.    Security Considerations . . . . . . . . . . . . . . . . . . 33
   7.    References  . . . . . . . . . . . . . . . . . . . . . . . .
   8.    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . 34

1.  Abstract

   This memo presents an elaboration of the SNMP administrative model
   set forth in [1]. This model provides a unified conceptual basis for
   administering SNMP protocol entities to support

     o authentication and integrity,

     o privacy,

     o access control, and

     o the cooperation of multiple protocol entities.

   Please send comments to the SNMP Security Developers mailing list
   ([e-mail]).

2.  Introduction

   This memo presents an elaboration of the SNMP administrative model
   set forth in [1]. It describes how the elaborated administrative
   model is applied to realize effective network management in a variety
   of configurations and environments.

   The model described here entails the use of distinct identities for
   peers that exchange SNMP messages. Thus, it represents a departure
   from the community-based administrative model set forth in [1]. By
   unambiguously identifying the source and intended recipient of each
   SNMP message, this new strategy improves upon the historical
   community scheme both by supporting a more convenient access control
   model and allowing for effective use of asymmetric (public key)
   security protocols in the future.

3.  Elements of the Model

3.1   SNMP Party

   A SNMP party  is a conceptual, virtual execution context whose
   operation is restricted (for security or other purposes) to an
   administratively defined subset of all possible operations of a
   particular SNMP protocol entity (see Section 3.2).  Whenever a SNMP
   protocol entity processes a SNMP message, it does so by acting as a
   SNMP party and is thereby restricted to the set of operations defined



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


   for that party. The set of possible operations specified for a SNMP
   party may be overlapping or disjoint with respect to the sets of
   other SNMP parties; it may also be a proper or improper subset of all
   possible operations of the SNMP protocol entity.

   Architecturally, each SNMP party comprises

     o a single, unique party identity,

     o a single authentication protocol and associated
       parameters by which all protocol messages originated by
       the party are authenticated as to origin and integrity,

     o a single privacy protocol and associated parameters by
       which all protocol messages received by the party are
       protected from disclosure,

     o a single MIB view (see Section 3.6) to which all
       management operations performed by the party are
       applied, and

     o a logical network location at which the party executes,
       characterized by a transport protocol domain and
       transport addressing information.

   Conceptually, each SNMP party may be represented by an ASN.1 value
   with the following syntax:


      SnmpParty ::= SEQUENCE {
        partyIdentity
           OBJECT IDENTIFIER,
        partyTDomain
           OBJECT IDENTIFIER,
        partyTAddr
           OCTET STRING,
        partyProxyFor
           OBJECT IDENTIFIER,
        partyMaxMessageSize
           INTEGER,
        partyAuthProtocol
           OBJECT IDENTIFIER,
        partyAuthClock
           INTEGER,
        partyAuthLastMsg
           INTEGER,
        partyAuthNonce
           INTEGER,



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


        partyAuthPrivate
           OCTET STRING,
        partyAuthPublic
           OCTET STRING,
        partyAuthLifetime
           INTEGER,
        partyPrivProtocol
           OBJECT IDENTIFIER,
        partyPrivPrivate
           OCTET STRING,
        partyPrivPublic
           OCTET STRING
      }


   For each SnmpParty value that represents a SNMP party, the following
   statements are true:

     o Its partyIdentity component is the party identity.

     o Its partyTDomain component is called the transport
       domain and indicates the kind of transport service by
       which the party receives network management traffic.
       An example of a transport domain is
       rfc1351Domain (SNMP over UDP, using SNMP
       parties).

     o Its partyTAddr component is called the transport
       addressing information and represents a transport
       service address by which the party receives network
       management traffic.

     o Its partyProxyFor component is called the proxied
       party  and represents the identity of a second SNMP
       party or other management entity with which
       interaction may be necessary to satisfy received
       management requests. In this context, the value
       noProxy signifies that the party responds to received
       management requests by entirely local mechanisms.

     o Its partyMaxMessageSize component is called the
       maximum message size and represents the length in
       octets of the largest SNMP message this party is
       prepared to accept.

     o Its partyAuthProtocol component is called the
       authentication protocol and identifies a protocol and a
       mechanism by which all messages generated by the party



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


       are authenticated as to integrity and origin. In this
       context, the value noAuth signifies that messages
       generated by the party are not authenticated as to
       integrity and origin.

     o Its partyAuthClock component is called the
       authentication clock and represents a notion of the
       current time that is specific to the party. The
       significance of this component is specific to the
       authentication protocol.

     o Its partyAuthLastMsg component is called the
       last-timestamp and represents a notion of time
       associated with the most recent, authentic protocol
       message generated by the party. The significance of this
       component is specific to the authentication protocol.

     o Its partyAuthNonce component is called the nonce
       and represents a monotonically increasing integer
       associated with the most recent, authentic protocol
       message generated by the party. The significance of this
       component is specific to the authentication protocol.

     o Its partyAuthPrivate component is called the private
       authentication key and represents any secret value
       needed to support the authentication protocol. The
       significance of this component is specific to the
       authentication protocol.

     o Its partyAuthPublic component is called the public
       authentication key and represents any public value that
       may be needed to support the authentication protocol.
       The significance of this component is specific to the
       authentication protocol.

     o Its partyAuthLifetime component is called the
       lifetime and represents an administrative upper bound
       on acceptable delivery delay for protocol messages
       generated by the party. The significance of this
       component is specific to the authentication protocol.

     o Its partyPrivProtocol component is called the privacy
       protocol and identifies a protocol and a mechanism by
       which all protocol messages received by the party are
       protected from disclosure. In this context, the value
       noPriv signifies that messages received by the party are
       not protected from disclosure.




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


     o Its partyPrivPrivate component is called the private
       privacy key and represents any secret value needed to
       support the privacy protocol. The significance of this
       component is specific to the privacy protocol.

     o Its partyPrivPublic component is called the public
       privacy key and represents any public value that may be
       needed to support the privacy protocol. The significance
       of this component is specific to the privacy protocol.

   If, for all SNMP parties realized by a SNMP protocol entity, the
   authentication protocol is noAuth and the privacy protocol is noPriv,
   then that protocol entity is called non-secure.

3.2   SNMP Protocol Entity

   A SNMP protocol entity is an actual process which performs network
   management operations by generating and/or responding to SNMP
   protocol messages in the manner specified in [1]. When a protocol
   entity is acting as a particular SNMP party (see Section 3.1), the
   operation of that entity must be restricted to the subset of all
   possible operations that is administratively defined for that party.

   By definition, the operation of a SNMP protocol entity requires no
   concurrency between processing of any single protocol message (by a
   particular SNMP party) and processing of any other protocol message
   (by a potentially different SNMP party). Accordingly, implementation
   of a SNMP protocol entity to support more than one party need not be
   multi-threaded. However, there may be situations where implementors
   may choose to use multi-threading.