GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1351

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1351.txt · Last modified: 1992/07/02 20:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki