doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc1351.txt b/doc/rfc/rfc1351.txt
new file mode 100644
index 0000000..deb2a87
--- /dev/null
+++ b/doc/rfc/rfc1351.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+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
+   (snmp-sec-dev@tis.com).
+
+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.
+
+   Architecturally, every SNMP entity maintains a local database that
+   represents all SNMP parties known to it -- those whose operation is
+   realized locally, those whose operation is realized by proxy
+   interactions with remote parties or devices, and those whose
+   operation is realized by remote entities. In addition, every SNMP
+   protocol entity maintains a local database that represents an access
+   control policy (see Section 3.11) that defines the access privileges
+   accorded to known SNMP parties.
+
+3.3   SNMP Management Station
+
+   A SNMP management station is the operational role assumed by a SNMP
+   party when it initiates SNMP management operations by the generation
+   of appropriate SNMP protocol messages or when it receives and
+   processes trap notifications.
+
+   Sometimes, the term SNMP management station is applied to partial
+
+
+
+Davin, Galvin, & McCloghrie                                     [Page 6]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   implementations of the SNMP (in graphics workstations, for example)
+   that focus upon this operational role. Such partial implementations
+   may provide for convenient, local invocation of management services,
+   but they may provide little or no support for performing SNMP
+   management operations on behalf of remote protocol users.
+
+3.4   SNMP Agent
+
+   A SNMP agent is the operational role assumed by a SNMP party when it
+   performs SNMP management operations in response to received SNMP
+   protocol messages such as those generated by a SNMP management
+   station (see Section 3.3).
+
+   Sometimes, the term SNMP agent is applied to partial implementations
+   of the SNMP (in embedded systems, for example) that focus upon this
+   operational role. Such partial implementations provide for
+   realization of SNMP management operations on behalf of remote users
+   of management services, but they may provide little or no support for
+   local invocation of such services.
+
+3.5   View Subtree
+
+   A view subtree is the set of all MIB object instances which have a
+   common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree
+   is identified by the OBJECT IDENTIFIER value which is the longest
+   OBJECT IDENTIFIER prefix common to all (potential) MIB object
+   instances in that subtree.
+
+3.6   MIB View
+
+   A MIB view is a subset of the set of all instances of all object
+   types defined according to the Internet-standard SMI [2] (i.e., of
+   the universal set of all instances of all MIB objects), subject to
+   the following constraints:
+
+     o Each element of a MIB view is uniquely named by an
+       ASN.1 OBJECT IDENTIFIER value. As such,
+       identically named instances of a particular object type
+       (e.g., in different agents) must be contained within
+       different MIB views. That is, a particular object
+       instance name resolves within a particular MIB view to
+       at most one object instance.
+
+     o Every MIB view is defined as a collection of view
+       subtrees.
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                     [Page 7]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+3.7   SNMP Management Communication
+
+   A SNMP management communication is a communication from one specified
+   SNMP party to a second specified SNMP party about management
+   information that is represented in the MIB view of the appropriate
+   party. In particular, a SNMP management communication may be
+
+     o a query by the originating party about information in
+       the MIB view of the addressed party (e.g., getRequest
+       and getNextRequest),
+
+     o an indicative assertion to the addressed party about
+       information in the MIB view of the originating party
+       (e.g., getResponse or trapNotification), or
+
+     o an imperative assertion by the originating party about
+       information in the MIB view of the addressed party
+       (e.g., setRequest).
+
+   A management communication is represented by an ASN.1 value with the
+   syntax
+
+
+      SnmpMgmtCom ::= [1] IMPLICIT SEQUENCE {
+        dstParty
+           OBJECT IDENTIFIER,
+        srcParty
+           OBJECT IDENTIFIER,
+        pdu
+           PDUs
+      }
+
+
+   For each SnmpMgmtCom value that represents a SNMP management
+   communication, the following statements are true:
+
+     o Its dstParty component is called the destination and
+       identifies the SNMP party to which the communication
+       is directed.
+
+     o Its srcParty component is called the source and
+       identifies the SNMP party from which the
+       communication is originated.
+
+     o Its pdu component has the form and significance
+       attributed to it in [1].
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                     [Page 8]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+3.8   SNMP Authenticated Management Communication
+
+   A SNMP authenticated management communication is a SNMP management
+   communication (see Section 3.7) for which the originating SNMP party
+   is (possibly) reliably identified and for which the integrity of the
+   transmission of the communication is (possibly) protected. An
+   authenticated management communication is represented by an ASN.1
+   value with the syntax
+
+
+      SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {
+        authInfo
+           ANY, - defined by authentication protocol
+        authData
+           SnmpMgmtCom
+      }
+
+
+   For each SnmpAuthMsg value that represents a SNMP authenticated
+   management communication, the following statements are true:
+
+     o Its authInfo component is called the authentication
+       information and represents information required in
+       support of the authentication protocol used by the
+       SNMP party originating the message. The detailed
+       significance of the authentication information is specific
+       to the authentication protocol in use; it has no effect on
+       the application semantics of the communication other
+       than its use by the authentication protocol in
+       determining whether the communication is authentic or
+       not.
+
+     o Its authData component is called the authentication
+       data and represents a SNMP management
+       communication.
+
+3.9   SNMP Private Management Communication
+
+   A SNMP private management communication is a SNMP authenticated
+   management communication (see Section 3.8) that is (possibly)
+   protected from disclosure. A private management communication is
+   represented by an ASN.1 value with the syntax
+
+
+
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                     [Page 9]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+      SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE {
+        privDst
+           OBJECT IDENTIFIER,
+        privData
+           [1] IMPLICIT OCTET STRING
+      }
+
+
+   For each SnmpPrivMsg value that represents a SNMP private management
+   communication, the following statements are true:
+
+     o Its privDst component is called the privacy destination
+       and identifies the SNMP party to which the
+       communication is directed.
+
+     o Its privData component is called the privacy data and
+       represents the (possibly encrypted) serialization
+       (according to the conventions of [3] and [1]) of a SNMP
+       authenticated management communication (see
+       Section 3.8).
+
+3.10   SNMP Management Communication Class
+
+   A SNMP management communication class corresponds to a specific SNMP
+   PDU type defined in [1]. A management communication class is
+   represented by an ASN.1 INTEGER value according to the type of the
+   identifying PDU (see Table 1).
+
+                  Get             1
+                  GetNext         2
+                  GetResponse     4
+                  Set             8
+                  Trap           16
+
+         Table 1: Management Communication Classes
+
+   The value by which a communication class is represented is computed
+   as 2 raised to the value of the ASN.1 context-specific tag for the
+   appropriate SNMP PDU.
+
+   A set of management communication classes is represented by the ASN.1
+   INTEGER value that is the sum of the representations of the
+   communication classes in that set. The null set is represented by the
+   value zero.
+
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 10]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+3.11   SNMP Access Control Policy
+
+   A SNMP access control policy is a specification of a local access
+   policy in terms of the network management communication classes which
+   are authorized between pairs of SNMP parties. Architecturally, such a
+   specification comprises three parts:
+
+     o the targets of SNMP access control - the SNMP parties
+       that may perform management operations as requested
+       by management communications received from other
+       parties,
+
+     o the subjects of SNMP access control - the SNMP parties
+       that may request, by sending management
+       communications to other parties, that management
+       operations be performed, and
+
+     o the policy that specifies the classes of SNMP
+       management communications that a particular target is
+       authorized to accept from a particular subject.
+
+   Access to individual MIB object instances is determined implicitly
+   since by definition each (target) SNMP party performs operations on
+   exactly one MIB view. Thus, defining the permitted access of a
+   (reliably) identified subject party to a particular target party
+   effectively defines the access permitted by that subject to that
+   target's MIB view and, accordingly, to particular MIB object
+   instances.
+
+   Conceptually, a SNMP access policy is represented by a collection of
+   ASN.1 values with the following syntax:
+
+
+      AclEntry ::= SEQUENCE {
+        aclTarget
+           OBJECT IDENTIFIER,
+        aclSubject
+           OBJECT IDENTIFIER,
+        aclPrivileges
+           INTEGER
+      }
+
+
+   For each such value that represents one part of a SNMP access policy,
+   the following statements are true:
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 11]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+     o Its aclTarget component is called the target and
+       identifies the SNMP party to which the partial policy
+       permits access.
+
+     o Its aclSubject component is called the subject and
+       identifies the SNMP party to which the partial policy
+       grants privileges.
+
+     o Its aclPrivileges component is called the privileges and
+       represents a set of SNMP management communication
+       classes that are authorized to be processed by the
+       specified target party when received from the specified
+       subject party.
+
+3.12   SNMP Proxy Party
+
+   A SNMP proxy party is a SNMP party that performs management
+   operations by communicating with another, logically remote party.
+
+   When communication between a logically remote party and a SNMP proxy
+   party is via the SNMP (over any transport protocol), then the proxy
+   party is called a SNMP native proxy party. Deployment of SNMP native
+   proxy parties is a means whereby the processing or bandwidth costs of
+   management may be amortized or shifted -- thereby facilitating the
+   construction of large management systems.
+
+   When communication between a logically remote party and a SNMP proxy
+   party is not via the SNMP, then the proxy party is called a SNMP
+   foreign proxy party. Deployment of foreign proxy parties is a means
+   whereby otherwise unmanageable devices or portions of an internet may
+   be managed via the SNMP.
+
+   The transparency principle that defines the behavior of a SNMP party
+   in general applies in particular to a SNMP proxy party:
+
+       The manner in which one SNMP party processes
+       SNMP protocol messages received from another
+       SNMP party is entirely transparent to the latter.
+
+   The transparency principle derives directly from the historical SNMP
+   philosophy of divorcing architecture from implementation. To this
+   dichotomy are attributable many of the most valuable benefits in both
+   the information and distribution models of the management framework,
+   and it is the architectural cornerstone upon which large management
+   systems may be built. Consistent with this philosophy, although the
+   implementation of SNMP proxy agents in certain environments may
+   resemble that of a transport-layer bridge, this particular
+   implementation strategy (or any other!) does not merit special
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 12]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   recognition either in the SNMP management architecture or in standard
+   mechanisms for proxy administration.
+
+   Implicit in the transparency principle is the requirement that the
+   semantics of SNMP management operations are preserved between any two
+   SNMP peers. In particular, the "as if simultaneous" semantics of a
+   Set operation are extremely difficult to guarantee if its scope
+   extends to management information resident at multiple network
+   locations. For this reason, proxy configurations that admit Set
+   operations that apply to information at multiple locations are
+   discouraged, although such operations are not explicitly precluded by
+   the architecture in those rare cases where they might be supported in
+   a conformant way.
+
+   Also implicit in the transparency principle is the requirement that,
+   throughout its interaction with a proxy agent, a management station
+   is supplied with no information about the nature or progress of the
+   proxy mechanisms by which its requests are realized. That is, it
+   should seem to the management station -- except for any distinction
+   in underlying transport address -- as if it were interacting via SNMP
+   directly with the proxied device. Thus, a timeout in the
+   communication between a proxy agent and its proxied device should be
+   represented as a timeout in the communication between the management
+   station and the proxy agent. Similarly, an error response from a
+   proxied device should -- as much as possible -- be represented by the
+   corresponding error response in the interaction between the proxy
+   agent and management station.
+
+3.13   Procedures
+
+   This section describes the procedures followed by a SNMP protocol
+   entity in processing SNMP messages. These procedures are independent
+   of the particular authentication and privacy protocols that may be in
+   use.
+
+3.13.1   Generating a Request
+
+   This section describes the procedure followed by a SNMP protocol
+   entity whenever either a management request or a trap notification is
+   to be transmitted by a SNMP party.
+
+    1. An ASN.1 SnmpMgmtCom value is constructed for
+       which the srcParty component identifies the originating
+       party, for which the dstParty component identifies the
+       receiving party, and for which the other component
+       represents the desired management operation.
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 13]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+    2. The local database is consulted to determine the
+       authentication protocol and other relevant information
+       for the originating SNMP party.
+
+    3. An ASN.1 SnmpAuthMsg value is constructed with
+       the following properties:
+
+        o Its authInfo component is constructed according
+          to the authentication protocol specified for the
+          originating party.
+
+          In particular, if the authentication protocol for the
+          originating SNMP party is identified as noAuth,
+          then this component corresponds to the OCTET
+          STRING value of zero length.
+
+        o Its authData component is the constructed
+          SnmpMgmtCom value.
+
+    4. The local database is consulted to determine the privacy
+       protocol and other relevant information for the receiving
+       SNMP party.
+
+    5. An ASN.1 SnmpPrivMsg value is constructed with the
+       following properties:
+
+        o Its privDst component identifies the receiving
+          SNMP party.
+
+        o Its privData component is the (possibly
+          encrypted) serialization of the SnmpAuthMsg
+          value according to the conventions of [3] and [1].
+
+          In particular, if the privacy protocol for the
+          receiving SNMP party is identified as noPriv, then
+          the privData component is unencrypted.
+          Otherwise, the privData component is processed
+          according to the privacy protocol.
+
+    6. The constructed SnmpPrivMsg value is serialized
+       according to the conventions of [3] and [1].
+
+    7. The serialized SnmpPrivMsg value is transmitted
+       using the transport address and transport domain for
+       the receiving SNMP party.
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 14]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+3.13.2   Processing a Received Communication
+
+   This section describes the procedure followed by a SNMP protocol
+   entity whenever a management communication is received.
+
+    1. If the received message is not the serialization (according
+       to the conventions of [3] and [1]) of an ASN.1
+       SnmpPrivMsg value, then that message is discarded
+       without further processing.
+
+    2. The local database is consulted for information about
+       the receiving SNMP party identified by the privDst
+       component of the SnmpPrivMsg value.
+
+    3. If information about the receiving SNMP party is absent
+       from the local database, or specifies a transport domain
+       and address which indicates that the receiving party's
+       operation is not realized by the local SNMP protocol
+       entity, then the received message is discarded without
+       further processing.
+
+    4. An ASN.1 OCTET STRING value is constructed
+       (possibly by decryption, according to the privacy
+       protocol in use) from the privData component of said
+       SnmpPrivMsg value.
+
+       In particular, if the privacy protocol recorded for the
+       party is noPriv, then the OCTET STRING value
+       corresponds exactly to the privData component of the
+       SnmpPrivMsg value.
+
+    5. If the OCTET STRING value is not the serialization
+       (according to the conventions of [3] and [1]) of an ASN.1
+       SnmpAuthMsg value, then the received message is
+       discarded without further processing.
+
+    6. If the dstParty component of the authData
+       component of the obtained SnmpAuthMsg value is
+       not the same as the privDst component of the
+       SnmpPrivMsg value, then the received message is
+       discarded without further processing.
+
+    7. The local database is consulted for information about
+       the originating SNMP party identified by the srcParty
+       component of the authData component of the
+       SnmpAuthMsg value.
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 15]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+    8. If information about the originating SNMP party is
+       absent from the local database, then the received
+       message is discarded without further processing.
+
+    9. The obtained SnmpAuthMsg value is evaluated
+       according to the authentication protocol and other
+       relevant information associated with the originating
+       SNMP party in the local database.
+
+       In particular, if the authentication protocol is identified
+       as noAuth, then the SnmpAuthMsg value is always
+       evaluated as authentic.
+
+   10. If the SnmpAuthMsg value is evaluated as
+       unauthentic, then the received message is discarded
+       without further processing, and an authentication failure
+       is noted.
+
+   11. The ASN.1 SnmpMgmtCom value is extracted from
+       the authData component of the SnmpAuthMsg
+       value.
+
+   12. The local database is consulted for access privileges
+       permitted by the local access policy to the originating
+       SNMP party with respect to the receiving SNMP party.
+
+   13. The management communication class is determined
+       from the ASN.1 tag value associated with the
+       SnmpMgmtCom value.
+
+   14. If the management communication class of the received
+       message is either 16 or 4 (i.e., Trap or GetResponse) and
+       this class is not among the access privileges, then the
+       received message is discarded without further processing.
+
+   15. If the management communication class of the received
+       message is not among the access privileges, then the
+       received message is discarded without further processing
+       after generation and transmission of a response message.
+       This response message is directed to the originating
+       SNMP party on behalf of the receiving SNMP party. Its
+       var-bind-list and request-id components are identical
+       to those of the received request. Its error-index
+       component is zero and its error-status component is
+       readOnly.
+
+   16. If the proxied party associated with the receiving SNMP
+       party in the local database is identified as noProxy,
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 16]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+       then the management operation represented by the
+       SnmpMgmtCom value is performed by the receiving
+       SNMP protocol entity with respect to the MIB view
+       identified with the receiving SNMP party according to
+       the procedures set forth in [1].
+
+   17. If the proxied party associated with the receiving SNMP
+       party in the local database is not identified as noProxy,
+       then the management operation represented by the
+       SnmpMgmtCom value is performed through
+       appropriate cooperation between the receiving SNMP
+       party and the identified proxied party.
+
+       In particular, if the transport domain associated with
+       the identified proxied party in the local database is
+       rfc1351Domain, then the operation requested by
+       the received message is performed by the generation of a
+       corresponding request to the proxied party on behalf of
+       the receiving party. If the received message requires a
+       response from the local SNMP protocol entity, then that
+       response is subsequently generated from the response (if
+       any) received from the proxied party corresponding to
+       the newly generated request.
+
+3.13.3   Generating a Response
+
+   This section describes the procedure followed by a SNMP protocol
+   entity whenever a response to a management request is generated.
+
+   The procedure for generating a response to a SNMP management request
+   is identical to the procedure for transmitting a request (see Section
+   3.13.1), except for the derivation of the transport domain and
+   address information.  In this case, the response is transmitted using
+   the transport domain and address from which the corresponding request
+   originated -- even if that is different from the transport
+   information recorded in the local database.
+
+4.  Application of the Model
+
+   This section describes how the administrative model set forth above
+   is applied to realize effective network management in a variety of
+   configurations and environments. Several types of administrative
+   configurations are identified, and an example of each is presented.
+
+4.1   Non-Secure Minimal Agent Configuration
+
+   This section presents an example configuration for a minimal, non-
+   secure SNMP agent that interacts with one or more SNMP management
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 17]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   stations. Table 2 presents information about SNMP parties that is
+   known both to the minimal agent and to the manager, while Table 3
+   presents similarly common information about the local access policy.
+
+   As represented in Table 2, the example agent party operates at UDP
+   port 161 at IP address 1.2.3.4 using the party identity gracie; the
+   example manager operates at UDP port 2001 at IP address 1.2.3.5 using
+   the identity george. At minimum, a non-secure SNMP agent
+   implementation must provide for administrative configuration (and
+   non-volatile storage) of the identities and transport addresses of
+   two SNMP parties: itself and a remote peer. Strictly speaking, other
+   information about these two parties (including access policy
+   information) need not be configurable.
+
+   Suppose that the managing party george wishes to interrogate the
+   agent named gracie by issuing a SNMP GetNext request message. The
+   manager consults its local database of party information. Because the
+   authentication protocol for the party george is recorded as noAuth,
+   the GetNext request message generated by the manager is not
+
+    Identity          gracie                george
+                      (agent)               (manager)
+    Domain            rfc1351Domain         rfc1351Domain
+    Address           1.2.3.4, 161          1.2.3.5, 2001
+    Proxied Party     noProxy               noProxy
+    Auth Prot         noAuth                noAuth
+    Auth Priv Key     ""                    ""
+    Auth Pub Key      ""                    ""
+    Auth Clock        0                     0
+    Auth Last Msg     0                     0
+    Auth Lifetime     0                     0
+    Priv Prot         noPriv                noPriv
+    Priv Priv Key     ""                    ""
+    Priv Pub Key      ""                    ""
+
+         Table 2: Party Information for Minimal Agent
+
+
+
+              Target    Subject   Privileges
+              gracie    george    3
+              george    gracie    20
+
+        Table 3: Access Information for Minimal Agent
+
+   authenticated as to origin and integrity. Because, according to the
+   manager's database, the privacy protocol for the party gracie is
+   noPriv, the GetNext request message is not protected from disclosure.
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 18]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   Rather, it is simply assembled, serialized, and transmitted to the
+   transport address (IP address 1.2.3.4, UDP port 161) associated in
+   the manager's database with the party gracie.
+
+   When the GetNext request message is received at the agent, the
+   identity of the party to which it is directed (gracie) is extracted
+   from the message, and the receiving protocol entity consults its
+   local database of party information. Because the privacy protocol for
+   the party gracie is recorded as noPriv, the received message is
+   assumed not to be protected from disclosure. Similarly, the identity
+   of the originating party (george) is extracted, and the local party
+   database is consulted. Because the authentication protocol for the
+   party george is recorded as noAuth, the received message is
+   immediately accepted as authentic.
+
+   The received message is fully processed only if the access policy
+   database local to the agent authorizes GetNext request communications
+   by the party george with respect to the agent party gracie. The
+   access policy database presented as Table 3 authorizes such
+   communications (as well as Get operations).
+
+   When the received request is processed, a GetResponse message is
+   generated with gracie as the source party and george, the party from
+   which the request originated, as the destination party. Because the
+   authentication protocol for gracie is recorded in the local party
+   database as noAuth, the generated GetResponse message is not
+   authenticated as to origin or integrity. Because, according to the
+   local database, the privacy protocol for the party george is noPriv,
+   the response message is not protected from disclosure. The response
+   message is transmitted to the transport address from which the
+   corresponding request originated -- without regard for the transport
+   address associated with george in the local database.
+
+   When the generated response is received by the manager, the identity
+   of the party to which it is directed (george) is extracted from the
+   message, and the manager consults its local database of party
+   information. Because the privacy protocol for the party george is
+   recorded as noPriv, the received response is assumed not to be
+   protected from disclosure. Similarly, the identity of the originating
+   party (gracie) is extracted, and the local party database is
+   consulted. Because the authentication protocol for the party gracie
+   is recorded as noAuth, the received response is immediately accepted
+   as authentic.
+
+   The received message is fully processed only if the access policy
+   database local to the manager authorizes GetResponse communications
+   by the party gracie with respect to the manager party george. The
+   access policy database presented as Table 3 authorizes such response
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 19]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   messages (as well as Trap messages).
+
+4.2   Secure Minimal Agent Configuration
+
+   This section presents an example configuration for a secure, minimal
+   SNMP agent that interacts with a single SNMP management station.
+   Table 4 presents information about SNMP 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
+   SNMP itself. A more elaborate example comprising an additional pair
+   of SNMP 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 SNMP parties for
+   which the authentication and privacy protocols are noAuth and noPriv,
+   respectively, in order to support clock synchronization (see [4]).
+   For clarity, these additional parties are not represented in this
+   example.
+
+     Identity          ollie                stan
+                       (agent)              (manager)
+     Domain            rfc1351Domain        rfc1351Domain
+     Address           1.2.3.4, 161         1.2.3.5, 2001
+     Proxied Party     noProxy              noProxy
+     Auth Prot         md5AuthProtocol      md5AuthProtocol
+     Auth Priv Key     "0123456789ABCDEF"   "GHIJKL0123456789"
+     Auth Pub Key      ""                   ""
+     Auth Clock        0                    0
+     Auth Last Msg     0                    0
+     Auth Lifetime     500                  500
+     Priv Prot         desPrivProtocol      desPrivProtocol
+     Priv Priv Key     "MNOPQR0123456789"   "STUVWX0123456789"
+     Priv Pub Key      ""                   ""
+
+      Table 4: Party Information for Secure Minimal Agent
+
+
+               Target   Subject   Privileges
+               ollie    stan      3
+               stan     ollie     20
+
+      Table 5: Access Information for Secure Minimal Agent
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 20]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   As represented in Table 4, 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 2001 at IP address 1.2.3.5 using
+   the identity stan. At minimum, a secure SNMP agent implementation
+   must provide for administrative configuration (and non-volatile
+   storage) of relevant information about two SNMP parties: itself and a
+   remote peer. Both ollie and stan authenticate all messages that they
+   generate by using the SNMP authentication protocol md5AuthProtocol
+   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 md5AuthProtocol, the public authentication key for
+   each SNMP party is never used in authentication and verification of
+   SNMP exchanges. Also, because the md5AuthProtocol is symmetric in
+   character, the private authentication key for each party must be
+   known to another SNMP 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 originated by the party stan are encrypted on
+   transmission 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
+   originated by the party ollie are encrypted on transmission 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.
+
+4.3   Proxy Configuration
+
+   This section presents examples of SNMP proxy configurations.  On one
+   hand, foreign proxy configurations provide the capability to manage
+   non-SNMP devices. On the other hand, native proxy configurations
+   allow an administrator to shift the computational burden of rich
+   management functionality away from network devices whose primary task
+   is not management.  To the extent that SNMP proxy agents function as
+   points of aggregation for management information, proxy
+   configurations may also reduce the bandwidth requirements of large-
+   scale management activities.
+
+   The example configurations in this section are simplified for
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 21]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   clarity: actual configurations may require additional parties in
+   order to support clock synchronization and distribution of secrets.
+
+4.3.1   Foreign Proxy Configuration
+
+   This section presents an example configuration by which a SNMP
+   management station may manage network elements that do not themselves
+   support the SNMP. This configuration centers on a SNMP proxy agent
+   that realizes SNMP management operations by interacting with a non-
+   SNMP device using a proprietary protocol.
+
+   Table 6 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 8 presents information about
+   the access policy specified by the local administration.
+
+   As represented in Table 6, the proxy agent party operates at UDP port
+   161 at IP address 1.2.3.5 using the party identity moe; the example
+   manager operates at UDP port 2002 at IP address 1.2.3.4 using the
+   identity larry. Both larry and moe authenticate all messages that
+   they generate by using the protocol md5AuthProtocol and their
+   distinct, private authentication keys. Although these private
+   authentication key values ("0123456789ABCDEF" and
+
+   Identity        larry               moe                 curly
+                   (manager)           (proxy)             (proxied)
+   Domain          rfc1351Domain       rfc1351Domain       acmeMgmtPrtcl
+   Address         1.2.3.4, 2002       1.2.3.5, 161        0x98765432
+   Proxied Party   noProxy             curly               noProxy
+   Auth Prot       md5AuthProtocol     md5AuthProtocol     noAuth
+   Auth Priv Key   "0123456789ABCDEF"  "GHIJKL0123456789"  ""
+   Auth Pub Key    ""                  ""                  ""
+   Auth Clock      0                   0                   0
+   Auth Last Msg   0                   0                   0
+   Auth Lifetime   500                 500                 0
+   Priv Prot       noPriv              noPriv              noPriv
+   Priv Priv Key   ""                  ""                  ""
+   Priv Pub Key    ""                  ""                  ""
+
+         Table 6: Party Information for Proxy Agent
+
+
+
+
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 22]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+     Identity        larry               moe
+                     (manager)           (proxy)
+     Domain          rfc1351Domain       rfc1351Domain
+     Address         1.2.3.4, 2002       1.2.3.5, 161
+     Proxied Party   noProxy             noProxy
+     Auth Prot       md5AuthProtocol     md5AuthProtocol
+     Auth Priv Key   "0123456789ABCDEF"  "GHIJKL0123456789"
+     Auth Pub Key    ""                  ""
+     Auth Clock      0                   0
+     Auth Last Msg   0                   0
+     Auth Lifetime   500                 500
+     Priv Prot       noPriv              noPriv
+     Priv Priv Key   ""                  ""
+     Priv Pub Key    ""                  ""
+
+       Table 7: Party Information for Management Station
+
+
+
+               Target   Subject   Privileges
+               moe      larry     3
+               larry    moe       20
+
+         Table 8: Access Information for Foreign Proxy
+
+   "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.
+
+   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 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 SNMP agent described above. The most significant
+   difference is that neither SNMP 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 SNMP 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").
+
+   For simplicity, privacy protocols are not addressed in this example
+   configuration, although their use would be necessary to the secure,
+   automated distribution of secret keys.
+
+4.5   MIB View Configurations
+
+   This section describes a convention for the definition of MIB views
+   and, using that convention, presents example configurations of MIB
+   views for SNMP parties.
+
+   A MIB view is defined by a collection of view subtrees (see Section
+   3.6), and any MIB view may be represented in this way. Because MIB
+   view definitions may, in certain cases, comprise a very large number
+   of view subtrees, a convention for abbreviating MIB view definitions
+   is desirable.
+
+   The convention adopted in [5] supports abbreviation of MIB view
+   definitions in terms of families of view subtrees that are either
+   included in or excluded from the definition of the relevant MIB view.
+   By this convention, a table locally maintained by each SNMP entity
+   defines the MIB view associated with each SNMP party realized by that
+   entity.  Each entry in the table represents a family of view subtrees
+   that (according to the status of that entry) is either included in or
+   excluded from the MIB view of some SNMP party. Each table entry
+   represents a subtree family as a pairing of an OBJECT IDENTIFIER
+   value (called the family name) together with a bitstring value
+   (called the family mask). The family mask indicates which
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 29]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   subidentifiers of the associated family name are significant to the
+   definition of the represented subtree family. For each possible MIB
+   object instance, that instance belongs to the view subtree family
+   represented by a particular table entry if
+
+     o the OBJECT IDENTIFIER name of that MIB
+       object instance comprises at least as many subidentifiers
+       as does the family name for said table entry, and
+
+     o each subidentifier in the name of said MIB object
+       instance matches the corresponding subidentifier of the
+       relevant family name whenever the corresponding bit of
+       the associated family mask is non-zero.
+
+   The appearance of a MIB object instance in the MIB view for a
+   particular SNMP party is related to the membership of that instance
+   in the subtree families associated with that party in local table
+   entries:
+
+     o If a MIB object instance belongs to none of the relevant
+       subtree families, then that instance is not in the MIB
+       view for the relevant SNMP party.
+
+     o If a MIB object instance belongs to the subtree family
+       represented by exactly one of the relevant table entries,
+       then that instance is included in, or excluded from, the
+       relevant MIB view according to the status of that entry.
+
+     o If a MIB object instance belongs to the subtree families
+       represented by more than one of the relevant table
+       entries, then that instance is included in, or excluded
+       from, the relevant MIB view according to the status of
+       the single such table entry for which, first, the associated
+       family name comprises the greatest number of
+       subidentifiers, and, second, the associated family name is
+       lexicographically greatest.
+
+   The subtree family represented by a table entry for which the
+   associated family mask is all ones corresponds to the single view
+   subtree identified by the family name for that entry.  Because the
+   convention of [5] provides for implicit extension of family mask
+   values with ones, the subtree family represented by a table entry
+   with a family mask of zero length always corresponds to a single view
+   subtree.
+
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 30]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+     Party Identity  Status     Family Name    Family Mask
+     lucy            include    internet       ""h
+
+         Table 13: View Definition for Minimal Agent
+
+   Using this convention for abbreviating MIB view definitions, some of
+   the most common definitions of MIB views may be conveniently
+   expressed. For example, Table 13 illustrates the MIB view definitions
+   required for a minimal SNMP entity that locally realizes a single
+   SNMP party for which the associated MIB view embraces all instances
+   of all MIB objects defined within the internet network management
+   framework.  The represented table has a single entry. The SNMP party
+   (lucy) for which that entry defines the MIB view is identified in the
+   first column. The status of that entry (include) signifies that any
+   MIB object instance belonging to the subtree family represented by
+   that entry may appear in the MIB view for party lucy. The family name
+   for that entry is internet, and the zero-length family mask value
+   signifies that the relevant subtree family corresponds to the single
+   view subtree rooted at that node.
+
+   Another example of MIB view definition (see Table 14) is that of a
+   SNMP protocol entity that locally realizes multiple SNMP parties with
+   distinct MIB views. The MIB view associated with the party lucy
+   comprises all instances of all MIB objects defined within the
+   internet network management framework, except those pertaining to the
+   administration of SNMP parties. In contrast, the MIB view attributed
+   to the party ricky contains only MIB object instances defined in the
+   system group of the internet-standard MIB together with those object
+   instances by which SNMP parties are administered.
+
+   A more complicated example of MIB view configuration illustrates the
+   abbreviation of related collections of view subtrees by view subtree
+   families (see Table 15). In this
+
+
+     Party Identity  Status     Family Name    Family Mask
+     lucy            include    internet       ""h
+     lucy            exclude    snmpParties    ""h
+     ricky           include    system         ""h
+     ricky           include    snmpParties    ""h
+
+         Table 14: View Definition for Multiple Parties
+
+   example, the MIB view associated with party lucy includes all object
+   instances in the system group of the internet-standard MIB together
+   with some information related to the second network interface
+   attached to the managed device. However, this interface-related
+   information does not include the speed of the interface. The family
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 31]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+   mask value "FFA0"h in the second table entry signifies that a MIB
+   object instance belongs to the relevant subtree family if the initial
+   prefix of its name places it within the ifEntry portion of the
+   registration hierarchy and if the eleventh subidentifier of its name
+   is 2. The MIB object instance representing the speed of the second
+   network interface belongs to the subtree families represented by both
+   the second and third entries of the table, but that particular
+   instance is excluded from the MIB view for party lucy because the
+   lexicographically greater of the relevant family names appears in the
+   table entry with status exclude.
+
+   The MIB view for party ricky is also defined in this example.  The
+   MIB view attributed to the party ricky includes all object instances
+   in the icmp group of the internet-standard MIB, together with all
+   information relevant to the fifth network interface attached to the
+   managed device. In addition, the MIB view attributed to party ricky
+   includes the number of octets received on the fourth attached network
+   interface.
+
+   While, as suggested by the examples above, a wide range of MIB view
+   configurations are efficiently supported by the abbreviated
+   representation of [5], prudent MIB design can sometimes further
+   reduce the size and complexity of the most
+
+
+    Party Identity  Status     Family Name        Family Mask
+    lucy            include    system             ""h
+    lucy            include    { ifEntry 0 2 }    "FFA0"h
+    lucy            exclude    { ifSpeed 2 }      ""h
+    ricky           include    icmp               ""h
+    ricky           include    { ifEntry 0 5 }    "FFA0"h
+    ricky           include    { ifInOctets 4 }   ""h
+
+          Table 15: More Elaborate View Definitions
+
+   likely MIB view definitions. On one hand, it is critical that
+   mechanisms for MIB view configuration impose no absolute constraints
+   either upon the access policies of local administrations or upon the
+   structure of MIB namespaces; on the other hand, where the most common
+   access policies are known, the configuration costs of realizing those
+   policies may be slightly reduced by assigning to distinct portions of
+   the registration hierarchy those MIB objects for which local policies
+   most frequently require distinct treatment. The relegation in [5] of
+   certain objects to a distinct arc in the MIB namespace is an example
+   of this kind of optimization.
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 32]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+5.  Compatibility
+
+   Ideally, all SNMP management stations and agents would communicate
+   exclusively using the secure facilities described in this memo. In
+   reality, many SNMP agents may implement only the insecure SNMP
+   mechanisms described in [1] for some time to come.
+
+   New SNMP agent implementations should never implement both the
+   insecure mechanisms of [1] and the facilities described here. Rather,
+   consistent with the SNMP philosophy, the burden of supporting both
+   sorts of communication should fall entirely upon managers. Perhaps
+   the best way to realize both old and new modes of communication is by
+   the use of a SNMP proxy agent deployed locally on the same system
+   with a management station implementation. The management station
+   implementation itself operates exclusively by using the newer, secure
+   modes of communication, and the local proxy agent translates the
+   requests of the manager into older, insecure modes as needed.
+
+   It should be noted that proxy agent implementations may require
+   additional information beyond that described in this memo in order to
+   accomplish the requisite translation tasks implicit in the definition
+   of the proxy function. This information could easily be retrieved
+   from a filestore.
+
+6.  Security Considerations
+
+   It is important to note that, in the example configuration for native
+   proxy operations presented in this memo, the use of symmetric
+   cryptography does not securely prevent direct communication between
+   the SNMP management station and the proxied SNMP agent.
+
+   While secure isolation of the management station and the proxied
+   agent can, according to the administrative model set forth in this
+   memo, be realized using symmetric cryptography, the required
+   configuration is more complex and is not described in this memo.
+   Rather, it is recommended that native proxy configurations that
+   require secure isolation of management station from proxied agent be
+   implemented using security protocols based on asymmetric (or "public
+   key") cryptography. However, no SNMP security protocols based on
+   asymmetric cryptography are currently defined.
+
+   In order to participate in the administrative model set forth in this
+   memo, SNMP implementations must support local, non-volatile storage
+   of the local party database. Accordingly, every attempt has been made
+   to minimize the amount of non-volatile storage required.
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 33]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+7.  References
+
+   [1] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
+       Network Management Protocol", RFC 1157, University of Tennessee
+       at Knoxville, Performance Systems International, Performance
+       Systems International, and the MIT Laboratory for Computer
+       Science, May 1990.  (Obsoletes RFC 1098.)
+
+   [2] Rose, M., and K. McCloghrie, "Structure and Identification of
+       Management Information for TCP/IP based internets", RFC 1155,
+       Performance Systems International, Hughes LAN Systems, May 1990.
+       (Obsoletes RFC 1065.)
+
+   [3] Information Processing -- Open Systems Interconnection --
+       Specification of Basic Encoding Rules for Abstract Syntax
+       Notation One (ASN.1), International Organization for
+       Standardization/International Electrotechnical Institute, 1987,
+       International Standard 8825.
+
+   [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
+       Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes
+       LAN Systems, Inc., MIT Laboratory for Computer Science, July
+       1992.
+
+   [5] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed
+       Objects for Administration of SNMP Parties", RFC 1353, Hughes LAN
+       Systems, Inc., MIT Laboratory for Computer Science, Trusted
+       Information Systems, Inc., July 1992.
+
+8.  Authors' Addresses
+
+       James R. Davin
+       MIT Laboratory for Computer Science
+       545 Technology Square
+       Cambridge, MA 02139
+
+       Phone:  (617) 253-6020
+       EMail:  jrd@ptt.lcs.mit.edu
+
+
+       James M. Galvin
+       Trusted Information Systems, Inc.
+       3060 Washington Road, Route 97
+       Glenwood, MD 21738
+
+       Phone:  (301) 854-6889
+       EMail:  galvin@tis.com
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 34]
+
+RFC 1351               SNMP Administrative Model               July 1992
+
+
+       Keith McCloghrie
+       Hughes LAN Systems, Inc.
+       1225 Charleston Road
+       Mountain View, CA 94043
+
+       Phone:  (415) 966-7934
+       EMail:  kzm@hls.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davin, Galvin, & McCloghrie                                    [Page 35]
+
\ No newline at end of file