Internet Draft SNMPV2d Aug 1995 A Decoupled Approach to SNMPv2 and Its Features (SNMPv2d) 1 Aug 1995 draft-ietf-snmpv2-features-00.txt Daniel O. Mahoney II Cabletron Systems, Inc. (dmahoney@ctron.com) Dave Harrington Cabletron Systems, Inc. (dbh@ctron.com) Dave Arneson Cabletron Systems, Inc. (arneson@ctron.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 January 1996 [Page 1] Internet Draft SNMPv2d Aug 1995 Abstract One of the problems with the original SNMPv2 drafts and the USEC version of the drafts is the tight coupling of all the features. To implement any feature requires all the features. This document proposes a solution to the tight coupling of the SNMPv2 features. It allows the developer and the user to choose which features are desired and which features are not for a given implementation or network. 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. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2]. The model described here is largely derived from the work of the SNMPv2 Working Group, as published in RFC1445 and RFC1447, and subsequent internet drafts. With the tight coupling of features in the original SNMPv2 Drafts and the USEC drafts, it seems that the all or nothing approach dictated by these documents may well be one of the root causes of many of the problems we have had to date with deploying SNMPv2. If the features are decoupled such that various subsets can be designed, implemented and used independently, then SNMPv2 can be more easily deployed. It also gives control back to the customers, allowing them to determine what features are needed. It is the purpose of this document to define feature sets and define how these feature sets can be used to implement subsets of the original SNMPv2 functionality, which can be used with a variety of security frameworks, commonly referred to as admin models. Each set consists of a set of SNMPv2 features, a PDU format, and any configuration MIBs needed (defined in [3] and [4]). The feature sets are: Mahoney [Page 2] Internet Draft SNMPv2d Aug 1995 1) SNMPv2 Message Defines message format used throughout this document Support of data filters, which allow two things: multiple entities to be addressed via a single agent and views to filter the data Multiple PDU formats 2) SnmpMinSecure-PDU contains SNMPv2 PDUs defined in [5] 3) SnmpPrivate-PDU encrypted data 4) Authenticated and Secure PDU similar to [6] Administrative Model Authentication Encryption The message format consist of a header with the multiple choices in the data portion of the message. This gives the flexibility to implement or use only the features desired. 2. Acknowledgments The authors want to thank Michael Kornegay and Alex Alten for their proposals, which started us off on this tangent. The authors also wish to acknowledge the contributions of the SNMPv2 Working Group. Credit for the name, "SNMPv2d", goes to Bob Natale. 3. Administrative Model Expectations It is expected that any administrative model used with the message and PDUs defined in this document will contain the following features: a MIB defining the communicating entities in the system (i.e the Party Table or a user MIB). This MIB should also allow for definition of authentication and privacy protocols and the keys associated with those protocols; A MIB mapping any communicating entities that receive requests to the appropriate data filter entry. 4. Feature Set Definitions Mahoney [Page 3] Internet Draft SNMPv2d Aug 1995 4.1 SNMPv2 Message This feature set defines the message format used in this proposal. A SNMPv2 message contains a single PDU; it is transmitted from one SNMPv2 entity to another SNMPv2 entity and contains management information for the destination SNMPv2 entity. Each of the following sections define the PDUs, which can be contained in the data portion of the message. It includes a local entity field, which refers to the contextLocalEntity in the ContextMIB [3]. The fields are defined as: = 2 = defines which dataFilterEntry to use = one of SnmpMinSecure-PDU, SnmpAuthSecure-PDU --------------------------------------- | | | | | version | dataFilterIdentity | data | | | | | --------------------------------------- 4.2 SnmpMinSecure-PDU This PDU contains SNMPv2 PDUs as defined in Protocol Operations for SNMPv2 [5]. 4.3 SnmpPrivate-PDU This PDU contains an encrypted form of a SnmpMinSecure-PDU. 4.4 SnmpAuthSecure-PDU This feature set adds several additional features including the concept of an administrative model, authentication and security. For more information about the rationale behind the authentication and privacy schemes used, read [6]. A Noauth/Nopriv mode is available for access control without authentication and privacy. To achieve this, model is set to 0, which means that the identity is read, but the AgentBoots, AgentTime and doubleEncryptedHash is ignored. The fields are defined as: = defines which admin model is being used; = is a field whose contents are defined by the admin model to uniquely identify which key information is to be used for authentication or decryption = contains any errors related to the security = as defined in [7] = as defined in [7] = the authentication hash as defined in Mahoney [Page 4] Internet Draft SNMPv2d Aug 1995 section 15 in [6] = contains a SnmpMinSecure or SnmpPrivate PDU ----------------------------------------------- | | | | | | | version | model | identity | AuthInfo | PDU | | | | | | | ----------------------------------------------- / \ --------------------------- --------------- / \ --------------------------------------------------------- | error- | AgentBoots | AgentTime | doubleEncryptedHash | | status | | | | | | | | | --------------------------------------------------------- 5. Message Definitions SNMPv2-Message ::= SEQUENCE { version INTEGER { SNMPv2 (1) }, dataFilterIdentity OCTET STRING, -- defined in [3] errorCode INTEGER { normal(0), encodingError(1), notSupported(2), -- specified conformance level -- is not supported modelError(3) } -- The model is not supported CHOICE { SnmpMinSecure-PDU, SnmpAuthSecure-PDU } } SnmpMinSecure-PDU ::= [1] IMPLICIT SEQUENCE { pdu PDUs } SnmpPrivate-PDU ::= [2] IMPLICIT SEQUENCE { SymmetricKeyEncryptedData IMPLICIT OCTET STRING -- encryption of an -- SnmpMinSecure-PDU -- defined in [6] Mahoney [Page 5] Internet Draft SNMPv2d Aug 1995 SnmpAuthSecure ::= [3] IMPLICIT SEQUENCE { model INTEGER, identity OCTET STRING, errorStatus INTEGER {noError(0) badIdentity(1), badPublicKey(2), badHash(3), badTimeStamp(4), badSymmetricKey(5), tooLargeSymmetricKey(6), noEncryptedDataAllowed(7), badEncryptedData(8), generalError(9)} agentBoots UINT32, agentTime UINT32, doubleAsymmetricEncryptedHash -- Encrypted one-way hash value. DoubleAsymmetricEncryptedHash, -- as defined in [6] CHOICE { SnmpMinSecure-PDU, SnmpPrivate-PDU } AgentBoots OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read STATUS current DESCRIPTION "a count of the number of times the agent has rebooted/re-initialized since agentID was last configured." ::= { agentMIB 1 } AgentTime OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read STATUS current DESCRIPTION "the number of seconds since agentBoots was last incremented." ::= { agentMIB 2 } AgentMaxMessageSize OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read STATUS current DESCRIPTION "the maximum size of a message which can be processed by this agent." ::= { agentMIB 3 } Mahoney [Page 6] Internet Draft SNMPv2d Aug 1995 AgentLifetime OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read STATUS current DESCRIPTION "the maximum lifetime of messages recevied by this agent". ::- { agent 4 } 6. Message Processing 6.1 Sending a message This section describes the procedure followed by an SNMPv2 entity whenever an SNMPv2 message or notification needs to transmitted. 1) Starting from the PDU, an SNMPv2 message is constructed by creating two successive ASN.1 SEQUENCES, where: - the PDU is a component of the first SEQUENCE, which could be an SnmpMinSecure-PDU, an SnmpPrivate-PDU, or an Snmpauthsecure-PDU, - the first SEQUENCE is a component of the second SEQUENCE, which corresponds exactly to an SNMPv2 message. In the SNMPv2 message, the dataFilterIdentity identifies the dataFilterEntry to use at the destination. 2) The constructed SNMPv2 message is encoded according to the conventions of [8] 3) The serialized SNMPv2 message is transmitted using the transport address and transport domain as specified by the administrative model currently in use. 6.2 Receiving a message This section describes the procedure followed by an SNMPv2 entity whenever a SNMPv2 message is received. This procedure is independent of the transport service address at which the message was received. (1) Increment the snmpStatsPackets [9]. If the message is not encoded correctly (according to Transport Mappings for SNMPv2 [8]), then snmpStatsEncodingErrors [8] is incremented and the message is dropped. (2) If the version number is not 1, then this message is processed in some other manner, or the message is dropped and snmpStatsEncodingErrors [9] is incremented. (3) An ASN.1 OCTET STRING value is constructed from the SNMPv2 message. Mahoney [Page 7] Internet Draft SNMPv2d Aug 1995 (4) The dataFilterIdentity is extracted from the message. If the dataFilterEntry corresponding to that dataFilterIdentity is not found, then a Report-PDU is sent. Generation of report PDUs is suppressed if disabled by the managed object, SNMPv2dnableReports [9]. (5) If the PDU Type is not supported by the recipient, then build an SNMPv2 messages, set the errorCode to notSupported, encode the message and send it to the original sender. (6) The PDU is now processing according to the rules defined in section 7. 7. PDU Processing It is mandatory that all SNMPv2 entities acting in an agent role be able to generate the following PDU types: Response-PDU, SNMPv2-Trap-PDU and Report-PDU; further, all such implementations must be able to receive the following PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU. It is mandatory that all SNMPv2 entities acting in a manager role be able to generate the following PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, InformRequest- PDU, and Response-PDU; further, all such implementations must be able to receive the following PDU types: Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU and Report-PDU. In the elements of procedure below, any field of a PDU which is not referenced by the relevant procedure is ignored by the receiving SNMPv2 entity. However, all components of a PDU, including those whose values are ignored by the receiving SNMPv2 entity, must have valid ASN.1 syntax and encoding. For example, some PDUs (e.g., the GetRequest-PDU) are concerned only with the name of a variable and not its value. In this case, the value portion of the variable binding is ignored by the receiving SNMPv2 entity. The unSpecified value is defined for use as the value portion of such bindings. For all generated PDUs, the message "wrapper" to encapsulate the PDU is generated and transmitted as specified in section 6. On receiving a management communication, the procedures defined in section 6 are followed. If these procedures indicate that the PDU contained within the message "wrapper" is to be processed, then the SNMPv2 context associated with the PDU defines the object resources which are visible to the operation. 7.1 SnmpMinSecure-PDU A SnmpMinSecure-PDU is generated and transmitted at the request of a SNMPv2 application as described in [10]. Mahoney [Page 8] Internet Draft SNMPv2d Aug 1995 Upon receipt of a SnmpMinSecure-PDU. the receiving SNMPv2 entity processes the PDU using the following steps: (1) Processes the PDU as described in [10]. (2) If the PDU was decoded correctly, then build an SNMPv2 message, set the errorCode to , encode the message and return it to the sender. (3) If the PDU cannot be decoded, then build an SNMPv2 message, set the errorCode to encodingError, encode the message and return it to the sender. 7.2 SnmpAuthSecure-PDU The PDU processing proposes the usage of a public key authentication protocol and symmetric key privacy protocol. However, at the discretion of the implementor, these usages may be changed to other protocols. For more discussion of the implications of using other protocols, see [6]. A SnmpAuthSecure-PDU is generated and transmitted at the request of a SNMPv2 application using the following steps: (1) Get the desired identity and put in the identity field of the PDU. (2) If the PDU is to be Noauth/Nopriv, then set model = 0 and skip to step 7; otherwise Set model to the value defined for use by the current admin model. (3) Get the current values of AgentBoots and AgentTime either from the agent or some stored value of them that the manager is sure is in sync with the agent's values. (4) Construct the PDU header setting the encrypted hash and error-status to zero. (5) Encode the PDU and compute the hash (see section 18 of [6]). (6) Double encrypt the hash value, first with the sender's private authentication key using the sender's authentication protocol and then with the recipient's public authentication key using the recipient's authentication protocol, which should be the same as the sender's. (7) Process the PDU contained in the data portion of this PDU. Upon receipt of a SnmpAuthSecure-PDU. the receiving SNMPv2 entity processes the PDU using the following steps: (1) Extract the model from the PDU header. If the model is not supported by this recipient, then build an SNMPv2 message with this PDU in the data portion of the message, set the errorCode to modelError, encode the message and return it to the sender. Mahoney [Page 9] Internet Draft SNMPv2d Aug 1995 (2) Extract the identity from the PDU header. (3) If the identity doesn't exist in the recipient's LCD, create an SnmpAuthSecure-PDU, set error-status to badIdentity, generate an SNMPv2-message and send the message to the original sender. (4) Retrieve the recipient's private key from the LCD and the sender's public key from the LCD using the identity from step 1. (5) Decrypt the doubly encrypted hash, using first the recipient's private key and then the sender's public key. (6) Compute a hash of the PDU (see section 18 of [6]). (7) Compare the computed hash and the decrypted hash. If they are not equal, create an SnmpAuthSecure-PDU, set error-status to badHash, generate an SNMPv2-message and send the message to the original sender. (8) Compare agentTime in header + lifetime to current agentTime in recipient's agentMIB. If the lifetime is exceeded, then create an SnmpAuthSecure-PDU, set error-status to badTimeStamp, generate an SNMPv2-message, set errorCode to normal and send the message to the original sender. (9) If the PDU contained in the data portion of the PDU processes without further error, then set the errorStatus to noErrors, build an SNMPv2 Message with errorCode set to normal, encode the message and return it to the sender (10) Process PDU in data portion of this PDU in accordance to rules defined in this section of the document for that type of PDU. 7.3 SnmpPrivate-PDU A SnmpPrivate-PDU is always contained in an SnmpAuthSecure-PDU. A SnmpPrivate-PDU is generated and transmitted at the request of a SNMPv2 application using the following steps: (1) Get privacy key and protocol to use from the LCD. (2) Encrypt the PDU to be sent using the privacy key. (3) Encode the results as an OCTET STRING. (4) Encrypt the privacy key using first the sender's private authentication key and then the recipient's public authentication key and encode as an OCTET STRING (5) These two values as a SEQUENCE are the PDU. Mahoney [Page 10] Internet Draft SNMPv2d Aug 1995 (6) These values then placed in the data portion of an SnmpAuthSecure-PDU and process according to the rules in section 7.2 of this document. Upon receipt of a SnmpPrivate-PDU. the receiving SNMPv2 entity processes the PDU using the following steps: (1) Decrypt the symmetric key, first using the recipient's private authentication key and then the sender's public authentication key. (2) Decode the data and decrypt it using the symmetric key. (3) Process the resulting SnmpMinSecure-PDU according to the rules defined in this section. 8. Security Considerations This document discusses Authentication and Encrpytion of SNMP and SNMPv2 messages. 9. References [1] Information processing systems - Open Systems Interconnection Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] 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, May 1995. [3] Dave Harrington, Sandeep Asija, Daniel O. Mahoney II, Data Filter MIB for Version 2 of the Simple Network Management Protocol (SNMPv2), draft-dbh-SNMPv2-dfilter-00.txt, July 1995. [4] Dave Harrington, Sandeep Asija, Daniel O. Mahoney II, Access Control MIB for Version 2 of the Simple Network Management Protocol (SNMPv2), draft-dbh-SNMPv2-access-00.txt, July 1995. [5] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose, Steven Waldbusser, Protocol Operations for SNMPv2 of the Simple Network Management Protocol (SNMPv2), August 1995, draft-mahoney-SNMPv2-proto-03.txt . [6] Alexander I. Alten, Security Encapsulation of Snmp, July 25, 1995 [7] Keith McCloghrie, Marshall T. Rose, Glenn Waters, James Galvin, User-based Security Model for SNMPv2 of the Simple Network Management Protocol (SNMPv2), draft-kzm-sec-alt-00.txt, June 1990 Mahoney [Page 11] Internet Draft SNMPv2d Aug 1995 [8] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven Waldbusser, Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2), draft-kzm-SNMPv2-tm-alt-00.txt, June 1995. [9] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven Waldbusser, Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2), draft-kzm-SNMPv2-mib-alt-00.txt, June 1995. [10] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven Waldbusser, Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2), draft-kzm-SNMPv2-proto-alt-00.txt, June 1995. 10. Authors Daniel O. Mahoney II Cabletron Systems, Inc. ATTN: Daniel O. Mahoney II Engineering - Durham PO Box 5005 35 Industrial Way Rochester, NH 03866-5005 USA Phone: +1 603 337 7355 Email: dmahoney@ctron.com David Harrington Cabletron Systems, Inc. ATTN: David Harrington Engineering - Durham P.O. Box 5005 Rochester NH 03866-5005 US Phone: +1 603 337 7357 Email: dbh@ctron.com David Arneson Cabletron Systems, Inc. ATTN: David Arneson Engineering - Merrimack P.O. Box 5005 Rochester NH 03866-5005 US Phone: +1 603 337 5238 Email: arneson@ctron.com Mahoney [Page 12] Internet Draft SNMPv2d Aug 1995 Table of Contents 1. Introduction ............................................. 1 2. Acknowledgments .......................................... 3 3. Administrative Model Expectations ........................ 3 4. Feature Set Definitions .................................. 3 4.1 SNMPv2 Message .......................................... 4 4.2 SnmpMinSecure-PDU ....................................... 4 4.3 SnmpPrivate-PDU ......................................... 4 4.4 SnmpAuthSecure-PDU ...................................... 4 5. Message Definitions ...................................... 5 6. Message Processing ....................................... 6 6.1 Sending a message ....................................... 7 6.2 Receiving a message ..................................... 7 7. PDU Processing ........................................... 8 7.1 SnmpMinSecure-PDU ....................................... 8 7.2 SnmpAuthSecure-PDU ...................................... 8 7.3 SnmpPrivate-PDU ......................................... 9 8. Security Considerations .................................. 11 9. References ............................................... 11 10. Authors ................................................. 12 Expires January 1996 [Page 13]