Internet Draft Administrative Model for SNMPv2 November 1994 Administrative Model for Version 2 of the Simple Network Management Protocol (SNMPv2) 1 November 1994 J. Galvin Trusted Information Systems galvin@tis.com K. McCloghrie Cisco Systems, Inc. kzm@cisco.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires May 1994 [Page 1] Internet Draft Administrative Model for SNMPv2 November 1994 1. Introduction A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework 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 SNMPv2 messages. Thus, it represents a departure from the community-based administrative model of the original SNMP [1]. By unambiguously identifying the source and intended recipient of each SNMPv2 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. 1.1. A Note on Terminology For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). 1.2. Change Log For the 1 November version: - recast RFC 1445 into an Internet-Draft, Expires May 1994 [Page 2] Internet Draft Administrative Model for SNMPv2 November 1994 - added Overview section, - rewrote Elements of the Model section, - fixed typos in the Elements of Procedure section, - rewrote parts of the Application of the Model section, and retitled it as Usage Examples. - tighted the definition of a proxy SNMPv2 agent, in order to remove confusion, and thereby deleted discussion of foreign proxies. - changed "local party database" to "local party datastore", and introduced LPD as an acronym for it. Expires May 1994 [Page 3] Internet Draft Administrative Model for SNMPv2 November 1994 2. Overview A management domain typically contains a large amount of management information. Each individual item of management information is an instance of a managed object type. The definition of a related set of managed object types is contained in a Management Information Base (MIB) module. Many such MIB modules are defined. For each managed object type it describes, a MIB module defines not only the semantics and syntax of that managed object type, but also the method of identifying an individual instance so that multiple instances of the same managed object type can be distinguished. 2.1. Contexts Typically, there are many instances of each managed object type within a management domain. For simplicity, the method for identifying instances specified by the MIB module does not allow each instance to be distinguished amongst the set of all instances within the management domain; rather, it allows each instance to be identified only within some scope or "context", where there are multiple such contexts within the management domain. Often, a context is a physical device, or perhaps, a logical device, although a context can also encompass multiple devices, or a subset of a single device, or even a subset of multiple devices. Thus, in order to identify an individual item of management information within the management domain, its context must be identified in addition to its object type and its instance. Note that this requires each context to have a globally-unique identification within the management domain. Note also that the same item of management information can exist in multiple contexts. For example, the managed object type, ifDescr [7], is defined as the description of a network interface. To identify the description of device-X's first network interface, three pieces of information are needed: device-X (the context), ifDescr (the managed object type), and "1" (the instance). Management information often changes over time. Thus, when naming a specific value of a managed object instance, an indication of time is needed. In most situations, it is the value at the current time which is of interest to the network manager. There are, however, situations where times other than the current time are of interest. For example, where the value of a device parameter after the device's next reboot is to be different to its current value. To accommodate this, each context has an associated notion of time, called its temporal domain. This allows, for example, one context to refer to the current values of a Expires May 1994 [Page 4] Internet Draft Administrative Model for SNMPv2 November 1994 device's parameters, and a different context to refer to the values that the same parameters for the same device will have after the device's next restart. 2.2. Authorization: Access Rights and MIB Views For security reasons, it is often valuable to be able to restrict the access rights of some management applications to only a subset of the management information in the management domain. To provide this capability, each context has an associated "MIB view" which details the specific set of managed object types (and optionally, the specific instances of object types) which can be accessed via that context. For example, if existing contexts were defined which together provided access to all management information in the domain, then one or more new contexts could be defined to have MIB views which are only subsets of the existing contexts, so that a management application only having access to the new contexts is restricted in the desired manner. Since managed object types (and their instances) are identified via the tree-like naming structure of ISO's OBJECT IDENTIFIERs [8, 3], it is convenient to define a MIB view as the combination of a set of "view subtrees", where each view subtree is a sub-tree within the managed object naming tree. Thus, a simple MIB view (e.g., all managed objects within the Internet Network Management Framework) can be defined as a single view sub-tree, while more complicated MIB views (e.g., all information relevant to a particular network interface) can be represented by the union of multiple view sub-trees. While any set of managed objects can be described by the union of some number of view subtrees, situations can arise that would require a very large number of view subtrees. This could happen, for example, when specifying all columns in one conceptual row of a MIB table because they would appear in separate subtrees, one per column, each with a very similar format. Because the formats are similar, the required set of subtrees can easily be aggregated into one structure. This structure is named a family of view subtrees after the set of subtrees that it conceptually represents. A family of view subtrees can either be included or excluded from a MIB view. In addition to restricting access rights by identifying (sub-)sets of management information, it is also valuable to restrict the operations allowed on the management information within a particular context. For example, one management application might be prohibited from write- access to a particular context, while another might be allowed to perform any type of operation. Expires May 1994 [Page 5] Internet Draft Administrative Model for SNMPv2 November 1994 2.3. Proxy The identification of a context is (architecturally) independent of the location at which its management information can be accessed. Of course, it is an SNMPv2 agent which responds to requests for access to management information. Each such request is contained within an SNMPv2 message which provides the capability to perform a single operation on a list of items of management information. Rather than having to identify the context as well as the managed object type and instance for each item of management information, each SNMPv2 message is concerned with only a single context. Thus, an SNMPv2 agent must be able to process requests for all items of management information within the one or more contexts it supports. In responding to a request, an SNMPv2 agent might be acting as a proxy for some other agent. The term "proxy" has historically been used very loosely, with multiple different meanings. These different meanings include (among others): (1) the forwarding of SNMPv2 requests on to other SNMP agents without regard for what managed object types are being accessed; for example, in order to forward SNMPv2 request from one transport domain to another, or to translate SNMPv2 requests into SNMPv1 requests; (2) the translation of SNMPv2 requests into operations of some non-SNMP management protocol; (3) support for aggregated managed objects where the value of one managed object instance depends upon the values of multiple other (remote) items of management information. Each of these scenarios can be advantageous; for example, support for aggregation for management information can significantly reduce the bandwidth requirements of large-scale management activities. However, using a single term to cover multiple different scenarios causes confusion. To avoid such confusion, the SNMPv2 administrative framework uses the term "proxy" with a much more tightly defined meaning, which covers only the first of those listed above. Specifically, the distinction between a regular SNMPv2 agent and a "proxy SNMPv2 agent" is simple: - a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests on to other agents according to the context, and irrespective of the Expires May 1994 [Page 6] Internet Draft Administrative Model for SNMPv2 November 1994 specific managed object types being accessed; - in contrast, an SNMPv2 agent which processes SNMPv2 requests according to the (names of the) individual managed object types and instances being accessed, is NOT a proxy SNMPv2 agent from the perspective of this administrative model. Thus, when an SNMPv2 agent acts as a proxy SNMPv2 agent for a particular context, not only is the information on how to forward the request specifically associated with that context, but the proxy SNMPv2 agent has no need of a detailed definition of the context's MIB view (since the proxy SNMPv2 agent forwards the request irrespective of the managed object types). In contrast, a non-proxy SNMPv2 agent must have the detailed definition of the context's MIB view, and even if it needs to issue requests to other agents, that need is dependent on the individual managed object instances being accessed (i.e., not only on the context). 2.4. Security One aspect of security was discussed above: the ability to assign different access rights to different management applications. The enforcement of these access rights requires the means not only to identify the source of a request but also to authenticate such identification. Another security capability which SNMPv2 (optionally) provides is the ability to protect the data within an SNMPv2 message from disclosure (i.e., to encrypt the data). This is particularly useful when sensitive data (e.g., passwords, or security keys) is accessed via SNMPv2 requests. Recommendations for which algorithms are best for authentication and privacy are subject to change. Such changes may occur as and when new research results on the vulnerability of various algorithms are published, and/or with the prevailing status of export control and patent issues. Thus, it is valuable to allow these algorithms to be specified as parameters, so that new algorithms can be accommodated over time. In particular, one type of algorithm which may become useful in the future is the set of algorithms associated with asymmetric (public key) cryptography. Note that not all accesses via SNMPv2 requests need to be secure. Indeed, there are purposes for which insecure access is required. One example of this is the ability of a management application to learn about devices of which it has no previous knowledge. Another example is Expires May 1994 [Page 7] Internet Draft Administrative Model for SNMPv2 November 1994 to perform any synchronization which the security algorithms need before they can be used to communicate securely. This need for insecure access is accommodated by defining one of the algorithms for authentication as providing no authentication, and similarly, one of the algorithms for privacy as providing no protection against disclosure. 2.5. Parties To provide these security capabilities, an SNMPv2 message needs to include the identity of its source and destination. Each such identity is specified as an SNMPv2 "party". Different parties have different security parameters, including the authentication and privacy algorithms and the security keys (if any) used. For any SNMPv2 message, the algorithm and parameters by which it is authenticated (or not) are those of its source party. Similarly, for any SNMPv2 message, the algorithm and parameters by which it is protected from disclosure (or not) are those of its destination party. When an SNMPv2 message is generated, the appropriate parties must be chosen so that the message will have the desired level of authentication and privacy. The parties' algorithms and security keys are used to add authentication information to the message, and (if necessary) to encrypt it. When an SNMPv2 message is received, the destination party's privacy algorithm is used to decrypt it (if necessary), and the source party's authentication information is used to authenticate it. Typically, an SNMPv2 party operates at one and only one location, although it is possible under some circumstances for an SNMPv2 party to operate from a different location. In any case, in order to authenticate the source party without having to rely on underlying transport mechanisms to provide authentication of transport addresses, it is necessary for a party to be globally unique, and have a globally unique identifier. 2.6. Authorization: Access Control As described above, an SNMPv2 message is associated with one context and two parties, where the context determines the set of management information being accessed by the message, and the parties are the identities of the source and destination. These properties of the message are used for access control. Specifically, access control is specified as a set of local access policies, where each such policy is a valid party/party/context triple against which to compare a received message. In addition, each such triple has an associated set of operations which are allowed for that triple. Thus, if the context and Expires May 1994 [Page 8] Internet Draft Administrative Model for SNMPv2 November 1994 the two parties specified by the received message are not a valid triple or the operation requested is not one of the operations allowed by the triple, then the requested access is denied. Note that a local access policy (a party/party/context triple) is also called an ACL (for historical reasons). 2.7. An SNMPv2 Entity's Local Party Datastore An SNMPv2 entity is an SNMPv2 protocol implementation used by an SNMPv2 agent and/or by one or more management applications. The local parties at an SNMPv2 entity are those which operate locally, and the local contexts are those for which the SNMPv2 entity acts as a (proxy or non- proxy) SNMPv2 agent in responding to requests. To implement the model described in the preceding sections, each SNMPv2 entity needs to retain its own set of information about contexts, parties, ACLs, and (in agents) views. This set of information is called the SNMPv2 entity's Local Party Datastore (LPD) because it is locally- stored information. Note, however, that the LPD contains information on both local and remote parties, local and/or remote contexts, local ACLs, and sometimes on remote ACLs as well. In order to allow an SNMPv2 entity's LPD to be configured, and to allow any synchronization which the security algorithms need before they can be used to communicate securely, the LPD needs to be accessible as managed objects. A MIB module to define these managed object types is contained in [4]. 2.8. Construction of an SNMPv2 Message The purpose of an SNMPv2 message is to contain an SNMPv2 PDU. (The PDU contains an operation-code, some additional request/response parameters and a list of names and values of specific managed object instances; for details, see [2].) To construct an SNMPv2 message, a number of headers are prepended in front of the PDU (specifically, each "header" is added as part of a new ASN.1 SEQUENCE). The header which is first prepended to the PDU contains the context and the source and destination parties. The second prepended header contains whatever authentication information needs to be transmitted as part of the message. The third identifies the destination party which determines if and how the remainder of the message (the PDU and the first two prepended headers) are encrypted. Expires May 1994 [Page 9] Internet Draft Administrative Model for SNMPv2 November 1994 3. Elements of the Model This section provides a more formal description of the model. 3.1. SNMPv2 Party An SNMPv2 party is an identity assumed by an SNMPv2 entity in order to restrict its operations (for security or other purposes) to an administratively defined subset of all SNMPv2 possible operations. Whenever an SNMPv2 entity processes an SNMPv2 message, it does so by operating as a SNMPv2 party and is thereby restricted to the set of operations defined for that party. The set of possible operations specified for an SNMPv2 party may be overlapping or disjoint with respect to the sets of other SNMPv2 parties. Each SNMPv2 party has a set of attributes which includes the following: partyIdentity - the value which uniquely identifies the party. partyTDomain - the kind of transport service by which the party receives network management traffic. An example of a transport domain is snmpUDPDomain (SNMPv2 over UDP, using SNMPv2 parties). partyTAddress - the transport service address at which the party normally receives network management traffic. This address is used in sending requests or trap notifications to the party (but not in responding to requests from the party). Note that there is no requirement that the party transmits network management traffic from this transport address. partyMaxMessageSize - the length in octets of the largest SNMPv2 message this party is prepared to accept. partyAuthProtocol - the authentication protocol by which all messages generated by the party are authenticated. In particular, the value 'noAuth' signifies that messages generated by the party are not authenticated. partyAuthClock - the party's authentication clock which represents a notion of the Expires May 1994 [Page 10] Internet Draft Administrative Model for SNMPv2 November 1994 current time that is specific to the party. The significance of this component is specific to the authentication protocol. partyAuthPrivate - the party's private authentication key which is any secret value needed to support the authentication protocol. The significance of this component is specific to the authentication protocol. partyAuthPublic - the party's public authentication key which is any publically- disclosable value that may be needed to support the authentication protocol. The significance of this component is specific to the authentication protocol. partyAuthLifetime - the 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. partyPrivProtocol - the privacy protocol by which all protocol messages received by the party are protected from disclosure. In particular, the value 'noPriv' signifies that messages received by the party are not protected from disclosure. partyPrivPrivate - the party's private privacy key which is any secret value needed to support the privacy protocol. The significance of this component is specific to the privacy protocol. partyPrivPublic - the party's public privacy key which is any publically-disclosable value that may be needed to support the privacy protocol. The significance of this component is specific to the privacy protocol. An SNMPv2 entity, which supports only SNMPv2 parties for which the authentication protocol is noAuth and the privacy protocol is noPriv, is called non-secure. 3.2. SNMPv2 Entity An SNMPv2 entity is an actual process which performs network management operations by generating and/or responding to SNMPv2 protocol messages in the manner specified in [2]. An SNMPv2 entity assumes the identity Expires May 1994 [Page 11] Internet Draft Administrative Model for SNMPv2 November 1994 of a particular local SNMPv2 party when processing an SNMPv2 message. An SNMPv2 entity is not required to process multiple protocol messages concurrently, regardless of whether such messages require it to assume the identity of the same or different SNMPv2 parties. Thus, implementation of an SNMPv2 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. Every SNMPv2 entity maintains a Local Party Datastore (LPD) which includes information on all local SNMPv2 parties, and on those remote SNMPv2 parties which are known locally, as well as other information (see below). 3.3. SNMPv2 Manager An SNMPv2 manager is the operational role assumed by an SNMPv2 entity when it acts in a manager role on behalf of management applications. Specifically, an SNMPv2 manager initiates SNMPv2 management operations by the generation of appropriate SNMPv2 protocol messages or when it receives and processes trap and inform notifications. 3.4. SNMPv2 Agent An SNMPv2 agent is the operational role assumed by an SNMPv2 entity when it acts in an agent role. Specifically, an SNMPv2 agent performs SNMPv2 management operations in response to received SNMPv2 protocol messages (except for inform notifications) generated by an SNMPv2 manager. 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. When the OBJECT IDENTIFIER prefix identifying a view subtree is longer than the OBJECT IDENTIFIER of an object type defined according to the SMI [3], then the use of such a view subtree for access control has granularity at the object instance level. Such granularity is considered beyond the scope of an SNMPv2 agent. As such, no Expires May 1994 [Page 12] Internet Draft Administrative Model for SNMPv2 November 1994 implementation of an SNMPv2 agent is required to support values of viewSubtree [4] which have more sub-identifiers than is necessary to identify a particular leaf object type. However, access control information is also used in determining which SNMPv2 entities operating on behalf of management applications should receive trap notifications (Section 4.2.6 of [2]). As such, agent implementors might wish to provide instance-level granularity in order to allow SNMPv2 entity operating on behalf of management applications to use fine-grain configuration of trap notifications. 3.6. View Subtree Families A family of view subtrees is 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 sub-identifiers of the associated family name are significant to the family's definition. For each possible managed object instance, that instance belongs to a particular view subtree family if both of the following conditions are true: o the OBJECT IDENTIFIER name of the managed object instance contains at least as many sub-identifiers as does the family name, and o each sub-identifier in the the OBJECT IDENTIFIER name of the managed object instance matches the corresponding sub-identifier of the family name whenever the corresponding bit of the associated family mask is non-zero. When the configured value of the family mask is all ones, the view subtree family is identical to the single view subtree identified by the family name. When the configured value of the family mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family having a family mask of zero length always corresponds to a single view subtree. 3.7. MIB View A MIB view is a subset of the set of all instances of all object types defined according to the SMI [3] (i.e., of the universal set of all instances of all MIB objects), subject to the following constraint: Expires May 1994 [Page 13] Internet Draft Administrative Model for SNMPv2 November 1994 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 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. A MIB view is defined as a collection of view subtree families, where each view subtree family has a type. The type determines whether the view subtree family is included in, or excluded from, the MIB view. A managed object instance is contained within the MIB view of a particular SNMPv2 context according to that instance's membership in the MIB view's collection of view subtree families: o If a managed object instance belongs to none of the relevant subtree families, then that instance is not in the MIB view. o If a managed object instance belongs to exactly one of the relevant subtree families, then that instance is included in, or excluded from, the relevant MIB view according to the type of that subtree family. o If a managed object instance belongs to more than one of the relevant subtree families, then that instance is included in, or excluded from, the relevant MIB view according to the type of a particular one of the subtree families to which it belongs. The particular subtree family is the one for which, first, the associated family name comprises the greatest number of sub- identifiers, and, second, the associated family name is lexicographically greatest. An SNMPv2 agent's LPD includes information on the definitions of all the MIB views which correspond to local non-proxy SNMPv2 contexts. 3.8. Proxy Context A proxy relationship exists when a proxy SNMPv2 agent processes a received management request by forwarding it to another entity, solely according to the SNMPv2 context of the received message. Such a context is called a proxy SNMPv2 context. When an SNMPv2 entity processes management requests for a proxy context, it is operating as a proxy SNMPv2 agent. Expires May 1994 [Page 14] Internet Draft Administrative Model for SNMPv2 November 1994 The transparency principle that defines the behavior of an SNMPv2 entity in general, applies in particular to a proxy SNMPv2 context: The manner in which a receiving SNMPv2 entity processes SNMPv2 protocol messages messages sent by another SNMPv2 entity is entirely transparent to the sending SNMPv2 entity. Implicit in the transparency principle is the requirement that the semantics of SNMPv2 management operations are preserved between any two SNMPv2 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 which support Set operations 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 SNMPv2 agent, an SNMPv2 manager is supplied with no information about the nature or progress of the proxy mechanisms used to perform its requests. That is, it should seem to the SNMPv2 manager (except for any distinction in an underlying transport address) as if it were interacting via SNMPv2 directly with the proxied device. Thus, a timeout in the communication between a proxy SNMPv2 agent and its proxied device should be represented as a timeout in the communication between the SNMPv2 manager and the proxy SNMPv2 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 SNMPv2 agent and SNMPv2 manager. 3.9. SNMPv2 Context An SNMPv2 context is a collection of management information accessible by an SNMPv2 entity. The collection of management information identified by a context is either proxy or non-proxy. A non-proxy SNMPv2 context has an associated MIB view. In this case, the SNMPv2 entity uses locally-defined mechanisms to access the management information identified by the SNMPv2 context. Each non-proxy SNMPv2 context has a set of attributes which include the following: contextIdentity - the value which uniquely identifies the SNMPv2 context. Expires May 1994 [Page 15] Internet Draft Administrative Model for SNMPv2 November 1994 contextViewIndex - the non-zero value which identifies this SNMPv2 context's MIB view. contextLocalEntity - the value which identifies the local entity (e.g., a local logical device) whose management information is contained in the SNMPv2 context. contextLocalTime - the temporal context of the management information contained in the SNMPv2 context. For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context. Each proxy SNMPv2 context has a set of attributes which include the following: contextIdentity - the value which uniquely identifies the SNMPv2 context. contextViewIndex - the value zero which indicates this SNMPv2 context is a proxy context. contextProxyDstParty - the SNMPv2 party to which SNMPv2 requests received for this context are forwarded. contextProxySrcParty - the SNMPv2 party to be used as the source SNMPv2 party when SNMPv2 requests received for this context are forwarded. contextProxyContext - the SNMPv2 context to be used in forwarding SNMPv2 requests received for this context. The applicability of contextProxySrcParty and contextProxyContext are dependent upon the partyTDomain attribute of the contextProxyDstParty party. An SNMPv2 entity's LPD includes information on all local contexts and on any remote contexts which are known locally. Expires May 1994 [Page 16] Internet Draft Administrative Model for SNMPv2 November 1994 3.10. SNMPv2 PDU An SNMPv2 PDU is defined in [2]. Each SNMPv2 PDU specifies a particular operation. The types of operation (see Table 1) are represented by the possible values of the ASN.1 tag for the appropriate PDU. GetRequest SetRequest SNMPv2-Trap GetNextRequest Response Inform GetBulkRequest Table 1: SNMPv2 Operation Types 3.11. SNMPv2 Message A SNMPv2 message contains a single SNMPv2 PDU, is transmitted from a source SNMPv2 party to a destination SNMPv2 party, and contains management information for an SNMPv2 context which is accessible by either the source or destination SNMPv2 party. In particular, an SNMPv2 message may be o a query by the source party about information accessible by the destination party (e.g., GetRequest, GetNextRequest, or GetBulkRequest), o an indicative assertion to the destination party about information accessible by the source party (e.g., Response, InformRequest, or SNMPv2-Trap), o an imperative assertion by the source party about information accessible by the destination party (e.g., SetRequest), or o a confirmation to the destination party about information received by the source party (e.g., a Response confirming an InformRequest). Starting from the PDU, an SNMPv2 message is constructed by creating three successive ASN.1 SEQUENCEs, where: - the PDU is a component of the first SEQUENCE, which is called an SNMPv2 management communication, Expires May 1994 [Page 17] Internet Draft Administrative Model for SNMPv2 November 1994 - the first SEQUENCE is a component of the second SEQUENCE, which is called an SNMPv2 authenticated management communication, and - the second SEQUENCE is a component of the third SEQUENCE, which is called an SNMPv2 private management communication. - the third SEQUENCE corresponds exactly to an SNMPv2 message. 3.12. SNMPv2 Management Communication An SNMPv2 management communication is an ASN.1 value with the following syntax: SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE { dstParty OBJECT IDENTIFIER, srcParty OBJECT IDENTIFIER, context OBJECT IDENTIFIER, pdu PDUs } where: o the dstParty component identifies the destination SNMPv2 party of the SNMPv2 message. o the srcParty component identifies the source SNMPv2 party of the SNMPv2 message. o the context component identifies the SNMPv2 context containing the management information referenced by the SNMPv2 message. o the pdu component is an SNMPv2 PDU as defined in [2]. Expires May 1994 [Page 18] Internet Draft Administrative Model for SNMPv2 November 1994 3.13. SNMPv2 Authenticated Management Communication An SNMPv2 authenticated management communication is an ASN.1 value with the following syntax: SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE { authInfo ANY, -- defined by authentication protocol authData SnmpMgmtCom } where: o the authInfo component contains the authentication information required in support of the authentication protocol used by the source SNMPv2 party. The detailed significance of the authentication information is specific to the authentication protocol in use, and its only use is in determining whether the communication is authentic or not. o the authData component is an SNMPv2 management communication. 3.14. SNMPv2 Private Management Communication An SNMPv2 private management communication is an ASN.1 value with the following syntax: SnmpPrivMsg ::= [1] IMPLICIT SEQUENCE { privDst OBJECT IDENTIFIER, privData [1] IMPLICIT OCTET STRING } where: o the privDst component identifies the destination SNMPv2 party of the SNMPv2 message. o the privData component is the (possibly encrypted) serialization (i.e., encoding according to the conventions of [5]) of an SNMPv2 authenticated management communication. Expires May 1994 [Page 19] Internet Draft Administrative Model for SNMPv2 November 1994 3.15. SNMPv2 Access Control Policy An SNMPv2 access control policy is a specification of a local access policy in terms of the types of SNMPv2 operations on an SNMPv2 context which are authorized between a pair of SNMPv2 parties. Each such local access policy, called an ACL (for historical reasons), has four attributes: aclTarget - the target - a destination SNMPv2 party that may perform management operations as requested by received SNMPv2 messages, aclSubject - the subject - a source SNMPv2 party that may request, by sending SNMPv2 messages, that management operations be performed, aclResources - the resources - an SNMPv2 context which identifies the management information on which requested management operations are to be performed, and aclPrivileges - the privileges - the types of SNMPv2 operations on the particular resources that the particular target is authorized to perform when requested by the particular subject. An SNMPv2 entity's LPD includes information on all the ACLs it uses to validate incoming requests. An SNMPv2 manager may also include remote ACLs in its LPD in order to determine which operation types are authorized by particular parties for a particular remote context. The application of SNMPv2 access control policy only occurs on receipt of management communications; it is not applied on transmission of SNMPv2 messages. Note, however, that similar information is used in determining the destinations of an SNMPv2-Trap [2]. Expires May 1994 [Page 20] Internet Draft Administrative Model for SNMPv2 November 1994 4. Elements of Procedure This section describes the procedures followed by an SNMPv2 entity in processing SNMPv2 messages. These procedures are independent of the particular authentication and privacy protocols that may be in use. 4.1. Generating a Request This section describes the procedure followed by an SNMPv2 entity whenever either a management request or a trap notification is to be transmitted by an SNMPv2 party. (1) A SnmpMgmtCom value is constructed for which the srcParty component identifies the originating party, for which the dstParty component identifies the receiving party, for which the context component identifies the desired SNMPv2 context, and for which the pdu component represents the desired management operation. (2) The LPD is consulted to determine the authentication protocol and other relevant information for the originating and receiving SNMPv2 parties. (3) A SnmpAuthMsg value is constructed with the following properties: Its authInfo component is constructed according to the authentication protocol specified for the originating party. In particular, if the authentication protocol for the originating SNMPv2 party is identified as noAuth, then this component corresponds to the OCTET STRING value of zero length. Its authData component is the constructed SnmpMgmtCom value. (4) The LPD is consulted to determine the privacy protocol and other relevant information for the receiving SNMPv2 party. (5) A SnmpPrivMsg value is constructed with the following properties: Its privDst component identifies the receiving SNMPv2 party. Its privData component is the (possibly encrypted) serialization of the SnmpAuthMsg value according to the conventions of [5]. Expires May 1994 [Page 21] Internet Draft Administrative Model for SNMPv2 November 1994 In particular, if the privacy protocol for the receiving SNMPv2 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 (i.e., encoded) according to the conventions of [5]. (7) The serialized SnmpPrivMsg value is transmitted using the transport address and transport domain (as specified in the LPD) for the receiving SNMPv2 party. Note that the above procedure does not include any application of any SNMPv2 access control policy (see section 2.13). 4.2. Processing a Received Communication This section describes the procedure followed by an SNMPv2 entity whenever a SNMPv2 message is received. (1) The snmpStatsPackets counter [7] is incremented. If the received message is not the serialization (according to the conventions of [5]) of an SnmpPrivMsg value, then that message is discarded without further processing. (If the first octet of the packet has the value hexadecimal 30, then the snmpStats30Something counter [7] is incremented prior to discarding the message; otherwise the snmpStatsEncodingErrors counter [7] is incremented.) (2) The LPD is consulted for information about the receiving SNMPv2 party identified by the privDst component of the SnmpPrivMsg value. (3) If information about the receiving SNMPv2 party is absent from the LPD, or indicates that the receiving party's operations are not performed by the local SNMPv2 entity, then the snmpStatsUnknownDstParties counter [7] is incremented and 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. Expires May 1994 [Page 22] Internet Draft Administrative Model for SNMPv2 November 1994 (5) If the OCTET STRING value is not the serialization (according to the conventions of [5]) of an SnmpAuthMsg value, then the received message is discarded without further processing, after the snmpStatsEncodingErrors counter [7] is incremented. (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, after the snmpStatsDstPartyMismatches counter [7] is incremented. (7) The LPD is consulted for information about the originating SNMPv2 party identified by the srcParty component of the authData component of the SnmpAuthMsg value. (8) If information about the originating SNMPv2 party is absent from the LPD, then the received message is discarded without further processing, after the snmpStatsUnknownSrcParties counter [7] is incremented. (9) The obtained SnmpAuthMsg value is evaluated according to the authentication protocol and other relevant information associated with the originating and receiving SNMPv2 parties in the LPD. 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 if the snmpV2EnableAuthenTraps object [7] is enabled, then the SNMPv2 entity sends authorizationFailure traps [7] according to its configuration (Section 4.2.6 of [2]). (11) The SnmpMgmtCom value is extracted from the authData component of the SnmpAuthMsg value. (12) The LPD is consulted for information about the SNMPv2 context identified by the context component of the SnmpMgmtCom value. (13) If information about the SNMPv2 context is absent from the LPD, then the received message is discarded without further processing, after the snmpStatsUnknownContexts counter [7] is incremented. Expires May 1994 [Page 23] Internet Draft Administrative Model for SNMPv2 November 1994 (14) The LPD is consulted for the access privileges authorized for the receiving SNMPv2 party to perform when requested by the originating SNMPv2 party upon the indicated SNMPv2 context. If no applicable local access policy is available, then the access privileges are the null set of operation types. (15) The SNMPv2 operation type is determined from the ASN.1 tag value associated with the PDUs component of the SnmpMgmtCom value. If the SNMPv2 operation type is either 32, 8, 2, or 1 (i.e., GetBulk, Set, GetNext or Get) and the SNMPv2 context is not realized by the local SNMPv2 entity, then the received message is discarded without further processing, after the snmpStatsUnknownContexts counter [7] is incremented. (16) If the SNMPv2 operation type is either 128, 64 or 4 (i.e., SNMPv2- Trap, Inform, or Response) and it is not among the authorized access privileges, then the received message is discarded without further processing, after the snmpStatsBadOperations counter [7] is incremented. (17) If the SNMPv2 operation type is not among the authorized 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 SNMPv2 party on behalf of the receiving SNMPv2 party. Its context, 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 authorizationError [2]. (18) If the SNMPv2 context is non-proxy, then the management operation represented by the SnmpMgmtCom value is performed by the receiving SNMPv2 entity with respect to the MIB view identified by the SNMPv2 context according to the procedures set forth in [2]. (19) If the SNMPv2 context is a proxy context, then the management operation represented by the SnmpMgmtCom value is performed through invoking the appropriate proxy procedures. For the sake of brevity and clarity, some situations in which an ASN.1 parsing error can occur were omitted from the above steps (e.g., the possibility that an authData component is not a correct serialization of a SnmpMgmtCom value); the snmpStatsEncodingErrors counter [7] is incremented whenever such an ASN.1 parsing error is discovered. Expires May 1994 [Page 24] Internet Draft Administrative Model for SNMPv2 November 1994 4.3. Generating a Response The procedure for generating a response to an SNMPv2 management request is identical to the procedure for transmitting a request (see Section 3.1), with these exceptions: (1) In Step 1, the dstParty component of the responding SnmpMgmtCom value is taken from the srcParty component of the original SnmpMgmtCom value; the srcParty component of the responding SnmpMgmtCom value is taken from the dstParty component of the original SnmpMgmtCom value; the context component of the responding SnmpMgmtCom value is taken from the context component of the original SnmpMgmtCom value; and, the pdu component of the responding SnmpMgmtCom value is the response which results from performing the operation specified in the original SnmpMgmtCom value. (2) In Step 7, the serialized SnmpPrivMsg value is transmitted using the transport address and transport domain from which its corresponding request originated - even if that is different from the transport information recorded in the LPD. Expires May 1994 [Page 25] Internet Draft Administrative Model for SNMPv2 November 1994 5. Usage Examples 5.1. Non-Secure Minimal Agent Configuration This section presents an example configuration for a minimal, non-secure SNMPv2 agent that interacts with one or more SNMPv2 managers. Table 2 presents information about local access policies, that are known both to the minimal agent and to the manager. Table 3 presents similarly common information about SNMPv2 parties. Target Subject Context Privileges gracie george device5 Get, GetNext & GetBulk george gracie device5 Response & SNMPv2-Trap Table 2: Access Information for Minimal Agent Identity gracie george (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2001 Auth Prot noAuth noAuth Auth Priv Key "" "" Auth Pub Key "" "" Auth Clock 0 0 Auth Lifetime 0 0 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 3: Party Information for Minimal Agent As shown in Table 3, 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 SNMPv2 agent implementation must provide for administrative configuration (and non-volatile storage) of the identities and transport addresses of two SNMPv2 parties: the local Expires May 1994 [Page 26] Internet Draft Administrative Model for SNMPv2 November 1994 and remote peers. Suppose that the SNMPv2 manager at 1.2.3.5 wishes to interrogate management information about the SNMPv2 context named "device5", by issuing an SNMPv2 GetNext request message. The manager consults its LPD (Table 2) to discover that management information for context "device5" is held by the party named gracie, and that the managing party george can be used to access that context. The manager further consults its LPD (Table 3) to obtain the parameters of the two parties: george and gracie. Because the authentication protocol for the party george is recorded as noAuth, the GetNext request message generated by the manager is not authenticated. Because the privacy protocol for the party gracie is noPriv, the GetNext request message is not protected from disclosure. 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 LPD with the party gracie. When the GetNext request message is received at the agent, the identity of the destination party (gracie) is extracted from the message, and the receiving entity consults its LPD. 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 source party (george) is extracted, and the LPD 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 agent's LPD authorizes GetNext request operations by the party george to the agent party gracie with respect to the SNMPv2 context "device5". The LPD information presented as Table 2 does authorize such operations (as well as Get and GetBulk operations). When the received request is processed, the agent generates a Response message which references the SNMPv2 context "device5" and identifies the source party as gracie (since gracie was the request's destination party), and the destination party as george (since george was the request's source party). The agent now consults its LPD. Because the authentication protocol for gracie is noAuth, the generated Response message is not authenticated. Because 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 LPD. Expires May 1994 [Page 27] Internet Draft Administrative Model for SNMPv2 November 1994 When the generated Response is received by the manager, the identity of the destination party (george) is extracted from the message, and the manager consults its LPD. 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 source party (gracie) is extracted, and the LPD 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 manager's LPD authorizes Response communications from the party gracie to the manager party george which reference the SNMPv2 context "device5". The LPD information presented as Table 2 does authorize such Response messages (as well as SNMPv2-Trap messages). 5.2. Secure Minimal Agent Configuration This section presents an example configuration for a secure, minimal SNMPv2 agent that interacts with a single SNMPv2 manager. Table 4 presents information about local access policies that are known both to the minimal agent and to the manager, while Table 5 presents similarly common information about SNMPv2 parties. 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 and protected from disclosure. This example requires encryption of all SNMPv2 messages. Another example having an additional pair of SNMPv2 parties could support the exchange of non-secret information in authenticated messages without incurring the cost of encryption. An actual secure agent configuration will require SNMPv2 parties for which the authentication and privacy protocols are noAuth and noPriv, respectively, in order to support clock synchronization (see [6]). For clarity, these additional parties are not shown in this example. Target Subject Context Privileges ollie stan device6 Get, GetNext & GetBulk stan ollie device6 Response & SNMPv2-Trap Table 4: Access Information for Secure Minimal Agent Expires May 1994 [Page 28] Internet Draft Administrative Model for SNMPv2 November 1994 Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2001 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" Auth Pub Key "" "" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot desPrivProtocol desPrivProtocol Priv Priv Key "MNOPQR0123456789" "STUVWX0123456789" Priv Pub Key "" "" Table 5: Party Information for Secure Minimal Agent As shown in Table 5, 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 SNMPv2 agent implementation must provide for administrative configuration (and non-volatile storage) of relevant information about a context and two SNMPv2 parties: one local and the other a remote peer. Both ollie and stan authenticate all messages that they generate by using the SNMPv2 authentication protocol v2md5AuthProtocol and their distinct, private authentication keys. Although these private authentication key values ("0123456789ABCDEF" and "GHIJKL0123456789") are presented here and in other examples in this section for expository purposes, knowledge of private authentication keys is normally confined to those portions of the protocol implementation that require it, and not made known to human beings. When using the v2md5AuthProtocol, the public authentication key for each SNMPv2 party is not used in authentication and verification of SNMPv2 exchanges. Also, because the v2md5AuthProtocol is symmetric in character, the private authentication key for each party must be known to each SNMPv2 entity 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 generated for transmission to the party stan are encrypted 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 generated for transmission to the party ollie are encrypted using the desPrivProtocol Expires May 1994 [Page 29] Internet Draft Administrative Model for SNMPv2 November 1994 protocol and private privacy key "MNOPQR0123456789"; they are correspondingly decrypted on reception. As with authentication keys, knowledge of private privacy keys is normally confined to those portions of the protocol implementation that require it, and not made known to human beings. 5.3. MIB View Configurations This section provides example configurations of MIB views illustrating both simple view subtrees, and more complicated uses of included and excluded families of view subtrees. Context Type Family Name Family Mask lucy included internet ''H Table 6: View Definition for Minimal Agent Table 6 illustrates the definition of a MIB view required for a minimal SNMPv2 entity that has a single SNMPv2 context for which the associated MIB view contains all instances of all MIB objects defined within the SNMPv2 Network Management Framework. The first column identifies the SNMPv2 context (lucy) for which the MIB view is defined. The type (included) signifies that any MIB object instance belonging to the view subtree family is contained in the MIB view for the SNMPv2 context lucy. The family name 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 7) is that of a SNMPv2 entity having multiple SNMPv2 contexts with distinct MIB views. The MIB view associated with the SNMPv2 context lucy comprises all instances of all MIB objects defined within the SNMPv2 Network Management Framework, except those pertaining to the administration of SNMPv2 parties. In contrast, the MIB view attributed to the SNMPv2 context ricky contains only MIB object instances defined in the system group of the Internet- standard MIB together with those object instances by which SNMPv2 parties are administered. Expires May 1994 [Page 30] Internet Draft Administrative Model for SNMPv2 November 1994 Context Type Family Name Family Mask lucy included internet ''H lucy excluded snmpParties ''H ricky included system ''H ricky included snmpParties ''H Table 7: View Definition for Multiple Contexts A more complicated example of MIB view configuration illustrates the use of view subtree families (see Table 8). In this example, the MIB view associated with the SNMPv2 context lucy includes all object instances in the system group of the Internet-standard MIB together with 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 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 sub- identifier 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 the SNMPv2 context lucy because the lexicographically greater of the relevant family names appears in the table entry with type excluded. The MIB view for the SNMPv2 context ricky is also defined in this example. The MIB view attributed to the SNMPv2 context 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 the SNMPv2 context ricky includes the number of octets received on the fourth attached network interface. Expires May 1994 [Page 31] Internet Draft Administrative Model for SNMPv2 November 1994 Context Type Family Name Family Mask lucy included system ''H lucy included { ifEntry 0 2 } 'FFA0'H lucy excluded { ifSpeed 2 } ''H ricky included icmp ''H ricky included { ifEntry 0 5 } 'FFA0'H ricky included { ifInOctets 4 } ''H Table 8: More Elaborate View Definitions While, as suggested by the examples above, a wide range of MIB view configurations are efficiently supported by the use of view subtree families, prudent MIB design can sometimes further reduce the size and complexity of the most 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. 5.4. Proxy Configuration This section presents an example configuration that supports SNMPv2 proxy operations - indirect interactions between an SNMPv2 agent and an SNMPv2 manager that are mediated by a second SNMPv2 agent which performs the role of a proxy SNMPv2 agent. Tables 9 and 10 present information the SNMPv2 manager's LPD: Table 9 for access control policies, and Table 10 for SNMPv2 parties. Tables 11, 12 and 13 present information in the SNMPv2 proxy agent's LPD: Table 11 for SNMPv2 parties, Table 12 for proxy contexts, and Table 13 for access control policies. (These configurations are simplified for clarity: actual configurations may require additional parties in order to support clock synchronization and distribution of secrets.) Expires May 1994 [Page 32] Internet Draft Administrative Model for SNMPv2 November 1994 Target Subject Context Privileges chico groucho ducksoup Get, GetNext & GetBulk groucho chico ducksoup Response & SNMPv2-Trap Table 9: Access Information for Management Station Identity groucho chico (manager) (proxy agent) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 2002 1.2.3.5, 161 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" Auth Pub Key "" "" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 10: Party Information for Management Station Expires May 1994 [Page 33] Internet Draft Administrative Model for SNMPv2 November 1994 Identity groucho chico (manager) (proxy agent) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 2002 1.2.3.5, 161 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "0123456789ABCDEF" "GHIJKL0123456789" Auth Pub Key "" "" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Identity harpo zeppo (proxy dst) (proxy src) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.6, 161 1.2.3.5, 161 Auth Prot v2md5AuthProtocol v2md5AuthProtocol Auth Priv Key "MNOPQR0123456789" "STUVWX0123456789" Auth Pub Key "" "" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 11: Party Information for Proxy Agent Context Proxy Destination Proxy Source Proxy Context ducksoup harpo zeppo bigstore bigstore groucho chico ducksoup Table 12: Proxy Contexts for Proxy Agent Expires May 1994 [Page 34] Internet Draft Administrative Model for SNMPv2 November 1994 Target Subject Context Privileges chico groucho ducksoup Get, GetNext & GetBulk groucho chico ducksoup Response & SNMPv2-Trap harpo zeppo bigstore Get, GetNext & GetBulk zeppo harpo bigstore Response & SNMPv2-Trap Table 13: Access Information for Proxy SNMPv2 Agent As shown in Table 11, the proxy SNMPv2 agent party operates at UDP port 161 at IP address 1.2.3.5 using the party identity chico; the example manager operates at UDP port 2002 at IP address 1.2.3.4 using the identity groucho; the proxy source party operates at UDP port 161 at IP address 1.2.3.5 using the party identity zeppo; and, the proxy destination party operates at UDP port 161 at IP address 1.2.3.6 using the party identity harpo. Messages generated by all four SNMPv2 parties are authenticated by using the authentication protocol v2md5AuthProtocol and their individual private authentication keys. Table 12 shows the proxy contexts known to the proxy SNMPv2 agent. In particular, the SNMPv2 context ducksoup is a proxy context that is satisfied when the SNMPv2 party zeppo communicates with the SNMPv2 party harpo and references the SNMPv2 context bigstore. In order to interrogate the proxied device associated with the context ducksoup (see Table 9), the SNMPv2 manager constructs an SNMPv2 message from party groucho containing a GetNext request for the SNMPv2 context ducksoup, and transmits it to the party chico operating (see Table 10) 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 chico, the originator of the message is verified as being the party groucho by using local knowledge (see Table 11) of the private authentication key "0123456789ABCDEF". Because party groucho is authorized to issue GetNext (as well as Get and GetBulk) requests to party chico for the SNMPv2 context ducksoup by the relevant access control policy (Table 13), the request is accepted. Because the LPD indicates that the SNMPv2 context ducksoup is a proxy context, the request is satisfied by its translation into a corresponding SNMPv2 GetNext request with source party zeppo and destination party harpo with SNMPv2 context bigstore. This new communication is authenticated using the private authentication key Expires May 1994 [Page 35] Internet Draft Administrative Model for SNMPv2 November 1994 "STUVWX0123456789" and transmitted to party harpo at the IP address 1.2.3.6. When this new request is received by the party harpo, the source of the message is verified as being the party zeppo by using local knowledge of the private authentication key "STUVWX0123456789". Because party zeppo is authorized to issue GetNext (as well as Get and GetBulk) requests to party harpo for the SNMPv2 context bigstore by the relevant access control policy (Table 13), the request is accepted. An SNMPv2 Response message representing the results of the query is then generated by party harpo to party zeppo referencing SNMPv2 context bigstore. This response communication is authenticated using the private authentication key "MNOPQR0123456789" and transmitted to party zeppo at IP address 1.2.3.5 (the source address for the corresponding request). When this response is received by party zeppo, the source of the message is verified as being the party harpo by using local knowledge (see Table 11) of the private authentication key "MNOPQR0123456789". Because party harpo is authorized to issue Response communications to party zeppo for SNMPv2 context bigstore by the relevant access control policy (Table 13), the response is accepted, and is used to construct a response to the original GetNext request, indicating an SNMPv2 context of ducksoup. This response, from party chico to party groucho, is authenticated using the private authentication key "GHIJKL0123456789" and is transmitted to the party groucho at IP address 1.2.3.4 (the source address for the original request). When this response is received by the party groucho, the source of the message is verified as being the party chico by using local knowledge (see Table 11) of the private authentication key "GHIJKL0123456789". Because party chico is authorized to issue Response messages to party groucho for SNMPv2 context ducksoup by the relevant access control policy (Table 13), the response is accepted, and the interrogation is complete. 5.5. 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. Expires May 1994 [Page 36] Internet Draft Administrative Model for SNMPv2 November 1994 Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2004 Auth Prot pkAuthProtocol pkAuthProtocol Auth Priv Key "0123456789ABCDEF" "" Auth Pub Key "0123456789abcdef" "ghijkl0123456789" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 14: Party Information for Public Key Agent The example configuration comprises a single SNMPv2 agent that interacts with a single SNMPv2 manager. Tables 14 and 15 present information about SNMPv2 parties as known to the agent and manager, respectively, while Table 4 presents information about local access policies that are known to both manager and agent. Identity ollie stan (agent) (manager) Domain snmpUDPDomain snmpUDPDomain Address 1.2.3.4, 161 1.2.3.5, 2004 Auth Prot pkAuthProtocol pkAuthProtocol Auth Priv Key "" "GHIJKL0123456789" Auth Pub Key "0123456789abcdef" "ghijkl0123456789" Auth Clock 0 0 Auth Lifetime 300 300 Priv Prot noPriv noPriv Priv Priv Key "" "" Priv Pub Key "" "" Table 15: Party Information for Public Key Management Station As shown in Table 14, 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 Expires May 1994 [Page 37] Internet Draft Administrative Model for SNMPv2 November 1994 generate by using the hypothetical SNMPv2 authentication protocol pkAuthProtocol and their individual private authentication keys. In most respects, the interaction between manager and agent in this configuration is almost identical to that in the example of the minimal, secure SNMPv2 agent described above. The most significant difference is that neither SNMPv2 party in the public key configuration has knowledge of the private key by which the other party authenticates its transmissions. Instead, for each received authenticated SNMPv2 communication, the identity of the originator is verified by applying an asymmetric cryptographic algorithm to the received message together with the public authentication key for the originating party. Thus, in this configuration, the agent knows the manager's public key ("ghijkl0123456789") but not its private key ("GHIJKL0123456789"); similarly, the manager knows the agent's public key ("0123456789abcdef") but not its private key ("0123456789ABCDEF"). Expires May 1994 [Page 38] Internet Draft Administrative Model for SNMPv2 November 1994 6. Security Considerations In order to participate in the administrative model set forth in this memo, SNMPv2 implementations must support local, non-volatile storage of the LPD. Accordingly, every attempt has been made to minimize the amount of non-volatile storage required. 7. Acknowledgements This document is a modified version of RFC 1445. 8. References [1] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, November 1994. [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, November 1994. [4] McCloghrie, K., and Galvin, J., "Party MIB for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, Cisco Systems, Trusted Information Systems, November 1994. [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, November 1994. [6] Galvin, J., and McCloghrie, K., "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, Trusted Information Systems, Cisco Systems, November 1994. Expires May 1994 [Page 39] Internet Draft Administrative Model for SNMPv2 November 1994 [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, November 1994. [8] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). Expires May 1994 [Page 40] Internet Draft Administrative Model for SNMPv2 November 1994 9. Authors' Addresses James M. Galvin Trusted Information Systems, Inc. 3060 Washington Road, Route 97 Glenwood, MD 21738 Phone: +1 301 854-6889 EMail: galvin@tis.com Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 5260 Email: kzm@cisco.com Expires May 1994 [Page 41] Internet Draft Administrative Model for SNMPv2 November 1994 Table of Contents 1 Introduction .................................................... 2 1.1 A Note on Terminology ......................................... 2 1.2 Change Log .................................................... 2 2 Overview ........................................................ 4 2.1 Contexts ...................................................... 4 2.2 Authorization: Access Rights and MIB Views .................... 5 2.3 Proxy ......................................................... 6 2.4 Security ...................................................... 7 2.5 Parties ....................................................... 8 2.6 Authorization: Access Control ................................. 8 2.7 An SNMPv2 Entity's Local Party Datastore ...................... 9 2.8 Construction of an SNMPv2 Message ............................. 9 3 Elements of the Model ........................................... 10 3.1 SNMPv2 Party .................................................. 10 3.2 SNMPv2 Entity ................................................. 11 3.3 SNMPv2 Manager ................................................ 12 3.4 SNMPv2 Agent .................................................. 12 3.5 View Subtree .................................................. 12 3.6 View Subtree Families ......................................... 13 3.7 MIB View ...................................................... 13 3.8 Proxy Context ................................................. 14 3.9 SNMPv2 Context ................................................ 15 3.10 SNMPv2 PDU ................................................... 17 3.11 SNMPv2 Message ............................................... 17 3.12 SNMPv2 Management Communication .............................. 18 3.13 SNMPv2 Authenticated Management Communication ................ 19 3.14 SNMPv2 Private Management Communication ...................... 19 3.15 SNMPv2 Access Control Policy ................................. 20 4 Elements of Procedure ........................................... 21 4.1 Generating a Request .......................................... 21 4.2 Processing a Received Communication ........................... 22 4.3 Generating a Response ......................................... 25 5 Usage Examples .................................................. 26 5.1 Non-Secure Minimal Agent Configuration ........................ 26 5.2 Secure Minimal Agent Configuration ............................ 28 5.3 MIB View Configurations ....................................... 30 5.4 Proxy Configuration ........................................... 32 5.5 Public Key Configuration ...................................... 36 6 Security Considerations ......................................... 39 7 Acknowledgements ................................................ 39 8 References ...................................................... 39 9 Authors' Addresses .............................................. 41 Expires May 1994 [Page 42] Internet Draft Administrative Model for SNMPv2 November 1994 Expires May 1994 [Page 43]