📄 rfc1445.txt
字号:
Network Working Group J. Galvin Request for Comments: 1445 Trusted Information Systems K. McCloghrie Hughes LAN Systems April 1993 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2) Status of this Memo This RFC specifes 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 Introduction .......................................... 2 1.1 A Note on Terminology ............................... 2 2 Elements of the Model ................................. 3 2.1 SNMPv2 Party ........................................ 3 2.2 SNMPv2 Entity ....................................... 6 2.3 SNMPv2 Management Station ........................... 7 2.4 SNMPv2 Agent ........................................ 7 2.5 View Subtree ........................................ 7 2.6 MIB View ............................................ 8 2.7 Proxy Relationship .................................. 8 2.8 SNMPv2 Context ...................................... 10 2.9 SNMPv2 Management Communication ..................... 10 2.10 SNMPv2 Authenticated Management Communication ...... 12 2.11 SNMPv2 Private Management Communication ............ 13 2.12 SNMPv2 Management Communication Class .............. 14 2.13 SNMPv2 Access Control Policy ....................... 14 3 Elements of Procedure ................................. 17 3.1 Generating a Request ................................ 17 3.2 Processing a Received Communication ................. 18 3.3 Generating a Response ............................... 21 Galvin & McCloghrie [Page i] RFC 1445 Administrative Model for SNMPv2 April 1993 4 Application of the Model .............................. 23 4.1 Non-Secure Minimal Agent Configuration .............. 23 4.2 Secure Minimal Agent Configuration .................. 26 4.3 MIB View Configurations ............................. 28 4.4 Proxy Configuration ................................. 32 4.4.1 Foreign Proxy Configuration ....................... 33 4.4.2 Native Proxy Configuration ........................ 37 4.5 Public Key Configuration ............................ 41 5 Security Considerations ............................... 44 6 Acknowledgements ...................................... 45 7 References ............................................ 46 8 Authors' Addresses .................................... 47 Galvin & McCloghrie [Page 1] RFC 1445 Administrative Model for SNMPv2 April 1993 1. Introduction A network 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 both authentication and authorization policies. Network management stations execute management applications which monitor and control network elements. Network elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled through 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). Galvin & McCloghrie [Page 2] RFC 1445 Administrative Model for SNMPv2 April 1993 2. Elements of the Model 2.1. SNMPv2 Party A SNMPv2 party is a conceptual, virtual execution environment whose operation is restricted (for security or other purposes) to an administratively defined subset of all possible operations of a particular SNMPv2 entity (see Section 2.2). Whenever a SNMPv2 entity processes a SNMPv2 message, it does so by acting as a SNMPv2 party and is thereby restricted to the set of operations defined for that party. The set of possible operations specified for a SNMPv2 party may be overlapping or disjoint with respect to the sets of other SNMPv2 parties; it may also be a proper or improper subset of all possible operations of the SNMPv2 entity. Architecturally, each SNMPv2 party comprises o a single, unique party identity, o a logical network location at which the party executes, characterized by a transport protocol domain and transport addressing information, o a single authentication protocol and associated parameters by which all protocol messages originated by the party are authenticated as to origin and integrity, and o a single privacy protocol and associated parameters by which all protocol messages received by the party are protected from disclosure. Galvin & McCloghrie [Page 3] RFC 1445 Administrative Model for SNMPv2 April 1993 Conceptually, each SNMPv2 party may be represented by an ASN.1 value with the following syntax: SnmpParty ::= SEQUENCE { partyIdentity OBJECT IDENTIFIER, partyTDomain OBJECT IDENTIFIER, partyTAddress OCTET STRING, partyMaxMessageSize INTEGER, partyAuthProtocol OBJECT IDENTIFIER, partyAuthClock INTEGER, partyAuthPrivate OCTET STRING, partyAuthPublic OCTET STRING, partyAuthLifetime INTEGER, partyPrivProtocol OBJECT IDENTIFIER, partyPrivPrivate OCTET STRING, partyPrivPublic OCTET STRING } For each SnmpParty value that represents a SNMPv2 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 snmpUDPDomain (SNMPv2 over UDP, using SNMPv2 parties). o Its partyTAddress component is called the transport addressing information and represents a transport service address by which the party receives network management traffic. Galvin & McCloghrie [Page 4] RFC 1445 Administrative Model for SNMPv2 April 1993 o Its partyMaxMessageSize component is called the maximum message size and represents the length in octets of the largest SNMPv2 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 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 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. 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 Galvin & McCloghrie [Page 5] RFC 1445 Administrative Model for SNMPv2 April 1993 component is specific to the privacy protocol.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -