Local Processing Model for version 3 of the Simple Network Management Protocol (SNMPv3) 09 May 1997 Bert Wijnen IBM T. J. Watson Research wijnen@vnet.ibm.com Randy Presuhn BMC Software, Inc. rpresuhn@bmc.com Keith 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). Abstract This document describes the Local Processing Model (LPM) for SNMP version 3 for use in the SNMPng architecture [SNMPng-ARCH]. This document defines the Elements of Procedure for accessing local management information. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this LPM. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 1] Draft Local Processing Model (LPM) for SNMPv3 May 1997 0. Issues - Does access control belong in LPM or in Security - How to do access control for Notifications - Interdependencies for contextTable, acTable, viewTable and subtreeFamilyTable - Should we expect specific PDU-types or can we assume MPC has done that checking. - Should we use UTF-8 for human readable names like contextName, viewName, groupName etc. - indexing of the viewTable by integer or viewName - do we need a contextTable or should we rely on entityMIB - acknowledgements needs expansion 0.1 Change Log [version 2.0] - Modifications as agreed at Memphis - Introduction and Terminology shortened, add ptr to Architecture - Follow new terminology (I may have missed some) - Trap Destinations and Trap Generation is now outside LPM - fixes/changes as a result of mailing list comments - Do away with snmpV3LpAcPrivileges - Keep contextTable with juts one column - Fix spelling errors (well at least some... we'll run through a spell-checker later). [version 1.x] - Initial versions before Memphis meeting Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 2] Draft Local Processing Model (LPM) for SNMPv3 May 1997 1. Introduction The architecture for the Next-Generation of the Simple Network Management Protocol (SNMPng) is composed of multiple subsystems, 1) a message processing and control subsystem, 2) a security subsystem, 3) a local processing subsystem, and 4) applications. It is important to understand the SNMPng architecture and the terminology of the architecture to understand where the model described in this document fits into the architecture and interacts with other models within the architecture. The reader is expected to have read and understood the description of the SNMPng architecture, as defined in [SNMPng-ARCH]. The Local Processing subsystem of an SNMP engine interacts with the Message Processing and Control subsystem using data elements defined by the Message Processing and Control model, within the constraints of the Architecture. A Local Processing model has the responsibility for processing the SNMP PDUs that operate on local instrumentation. As such, the Local Processing model applies access control and invokes method routines to access management information and then prepares a response to the received SNMP request. It is the purpose of this document to define a specific model of the Local Processing subsystem, designated the SNMP version 3 Local Processing model. 1.2 Local Processing Local Processing may occur in an SNMPv3 engine acting in an agent role in response to SNMPv3 request messages from an SNMPv3 engine acting in a manager role. These request messages include these types of operations: GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations. Local Processing only occurs if the request is targeted at local management information as determined by the contextEngineID in the Naming-Scope of a scopedPDU. It is the Message Processing and Control module that determines if the contextEngineID refers to the current (local) SNMPv3 engine and if so, to direct the scopedPDU to the Local Processing module. Local Processing almost always results in the production of a response, (sometimes including error or other exceptional indicators), termed the Response-PDU. Local Processing can also result in the production of an Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 3] Draft Local Processing Model (LPM) for SNMPv3 May 1997 error report, termed the Report-PDU. 1.3 Local Configuration Datastore To implement the model described in this document, each SNMPv3 engine needs to retain its own set of information about access rights and policies, and the like. This set of information is called the SNMPv3 engine's Local Configuration Datastore (LCD) because it is locally-stored information. In order to allow an SNMPv3 engine's LCD to be remotely configured, portions of the LCD need to be accessible as managed objects. A MIB module, the SNMPv3 Local Processing Model Configuration MIB, which defines these managed object types is included in this document. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 4] Draft Local Processing Model (LPM) for SNMPv3 May 1997 2. Elements of the Model This section contains definitions to realize the access control applied by this Local Processing Model. 2.1 Groups A groupName identifies a group (set) of zero or more security entities on whose behalf SNMP management objects are being accessed. It is the responsibility of the Message Processing and Control module (MPC) to determine in an authoritative manner for which groupName an incoming SNMP request is being processed. This SNMPv3 Local Processing model requires the groupName to be passed as input to the Local Processing module when a PDU is handed to it for processing. 2.2 Level of Security (LoS) The LoS identifies the Level of Security (in terms of message security) used for transmitting the SNMP message. It is the responsibility of the Message Processing and Control module to determine in an authoritative manner the LoS that was used for an incoming SNMP message. It is the responsibility of the Local Processing module to take the LoS into consideration when applying access control. This Local Processing Model recognizes three different LoS levels: - without authentication and without privacy - with authentication but without privacy - with authentication and with privacy This Local Processing Model requires the LoS to be passed as input to the Local Processing module when a message is handed to it for local processing. 2.3 Contexts An SNMP context is a collection of management information accessible by an SNMP agent. An item of management information may exist in more than one context. An SNMP agent potentially has access to many contexts. 2.4 scopedPDU A scopedPDU contains a Naming-Scope that unambiguously identifies an SNMP agent and the context, (locally) accessible by that agent, to which the SNMP management information in the SNMP-PDU refers. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 5] Draft Local Processing Model (LPM) for SNMPv3 May 1997 A Naming-Scope contains a contextEngineID that unambiguously identifies the SNMP agent which has (local) access to the management information referred to by the contextName and the SNMP-PDU. A Naming-Scope contains a contextName which unambiguously identifies an SNMP context accessible by the SNMP agent to which the SNMP-PDU is directed. It is the responsibility of the Message Processing and Control module to determine in an authoritative manner if the contextEngineID refers to the current (local) SNMPv3 engine and if so to direct the SNMP message to the Local Processing module for local processing. This Local Processing Model requires the scopedPDU to be passed as input to the Local Processing module if a message is handed to it. Editor's notes: We (Keith, Randy and Bert) believe it would be better to not use a scopedPDU as input/output to the LPM but instead use contextName plus PDU as input/output. After all, the contextEngineID is irrelevant in the LPM and is in fact only used/known in the MPC. End Editor's notes. 2.5 Access Policy The access policy of this Local Processing model determines the access rights of groups (representing zero, one or more security entities which have the same access rights). For a particular context (contextName) to which a group (groupName) has access using a particular Level of Security (LoS), that group's access rights are given by a list of authorized operations, and a read-view and a write-view. The read-view is the set of object instances authorized for the group when reading objects. Reading objects occurs when processing a retrieval (Get, GetNext, GetBulk) operation and when sending a notification (Trap). The write-view is the set of object instances authorized for the group when writing objects. Writing objects occurs when processing a Set operation. 2.6. Error Reporting Editor's notes: (additional) pieces of this should be specified in the MPC and Security Model. MPC does not do any details on error reporting yet, so here it is End Editor's notes. While processing a received communication, an SNMPv3 engine may determine that the message is unacceptable. In this case, Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 6] Draft Local Processing Model (LPM) for SNMPv3 May 1997 the appropriate error counter is incremented and the received message is discarded without further processing. If an SNMPv3 engine is processing a received Get, GetNext, GetBulk, Set or Inform PDU and determines that a message is unacceptable and the reportableFlag indicates that a report may be generated, then after incrementing the appropriate counter, it is required to generate a message containing a report PDU, with the same context as the received message, and to send it to the transport address which originated the received message. For all report PDUs, generated by the Local Processing module, the Level of Security (LoS) for sending the report-PDU is unauthenticated. -- Editor's note: There were some opinions in the SNMPv3 mailing list that the reports should be send with same LoS if at all possible. Originally the v2adv team had agreed that all report PDUs would travel unauthenticated (except for notInTimeWindow). The editors still think that this indeed is best. -- End Editor's note -- Editor's note: The following about the reportableFlag is already specified in MPC document, so maybe we do not need to repeat it here? -- End editor's note The reportableFlag should never be set for a message that contains a Response, SNMPv2-Trap or Report operation. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 7] Draft Local Processing Model (LPM) for SNMPv3 May 1997 3. Elements of Procedure This section describes the procedures followed by the Local Processing module that implements this Local Processing Model when processing or generating a scopedPDU. For clarity, some of the details of this procedure are left out and are described in Section 3.1.1 and its sub-sections. 3.1 Processing a Received scopedPDU This section describes the procedure followed by the Local Processing module whenever it receives a scopedPDU for local processing. (1) The PDU portion of the scopedPDU is processed. If the serialized PDU value is not the serialization (according to the conventions of [RFC1906]) of a PDU value, then the snmpInASNParseErrs counter [RFC1907] is incremented, and the received scopedPDU is discarded without further processing. An error indication is returned to the calling module. (2) The SNMPv2 operation type is determined from the ASN.1 tag value associated with the PDUs component. (3) If the SNMPv2 operation type is either a Response, SNMPv2-Trap, Inform or Report operation, then the snmpV3UnauthorizedOperations counter is incremented. Then: - If the SNMPv2 operation type is an Inform operation, then an error report is generated. - The scopedPDU is discarded without further processing. - An error indication is returned to the calling module. Editor's notes: the above PDU-types should not be passed to the LPM. So it seems that the MPC also must define some SNMP PDU processing for Report, Response, Trap, Inform. I first thought we could return a response with an authorizationError (in SNMP PDU)... On second thoughts, we cannot do that because we cannot return a response to a Response, Trap or Report. We can also not return a report to a Response, Trap or Report. So I think the above is the best we can do. End Editor's notes. (4) The LCD is consulted for information about the SNMP context identified by the contextName. If information about this SNMP context is absent from the LCD, then the snmpV3LpStatsUnknownContexts counter is incremented, a report PDU [RFC1905] is generated, and the received scopedPDU is discarded without further processing. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 8] Draft Local Processing Model (LPM) for SNMPv3 May 1997 Editor's notes: The above means we have a contextTable within LPM. We had some discussion on this on the mailing list and it seems most people feel it is useful to have a contextTable. End Editor's notes. (5) The LCD is consulted for information about the SNMP group identified by the groupName. If information about this SNMP group is absent from the LCD, then the snmpV3LpStatsUnknownGroups counter is incremented, a report PDU [RFC1905] is generated, and the received scopedPDU is discarded without further processing. Note that a group is considered to be known if the groupName is used as an index in the snmpV3LpAcTable and has at least one row with a status of "active". (6) If the SNMPv2 operation type is either a Get, GetNext, GetBulk, or Set operation, then: a) the LCD is consulted for access rights authorized for communications using the indicated LoS, on behalf of the indicated group, and concerning management information in the indicated context for the particular SNMPv2 operation type. A Get, GetNext and GetBulk represent a read operation type (for which a read-view must exist) and a Set represents a write operation type (for which a write-view must exist). b) if the SNMPv2 operation type is not among the authorized access rights, then a response-PDU is prepared with the error-index set to zero and the error-status set to authorizationError [RFC1905]. The response-PDU is returned to the calling module. c) the management operation represented by the SNMPv2 operation type is performed by the receiving LPM with respect to the relevant MIB view within the SNMP context according to the procedures set forth in [RFC1905], where the relevant MIB view is determined according to the contextName, groupName and the LoS values and the SNMPv2 operation type requested. d) An SNMPv2 Response-PDU is produced and presented to the calling module for further processing. The LPM uses the scopedPDU-MMS to ensure that the produced Response-PDU does not exceed the maximum message size. (7) If the SNMPv2 operation type is anything that has not yet been processed, then it is an unknown PDU-type. The snmpV3UnauthorizedOperations counter is incremented and the received scopedPDU is discarded without further processing. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 9] Draft Local Processing Model (LPM) for SNMPv3 May 1997 An error indication is returned to the calling module. 3.1.1. Additional Details For the sake of clarity and to prevent the above procedure from being even longer, the following details were omitted from the above procedure. 3.1.1.1. ASN.1 Parsing Errors For ASN.1 parsing errors, the snmpInASNParseErrs counter [RFC1907] is incremented and a report PDU is generated whenever such an ASN.1 parsing error is discovered. However, if the parsing error causes the information able to be extracted from the message to be insufficient for generating a report PDU, then the report PDU is not sent. 3.1.1.2. Generation of a Report PDU Some steps specify that the received scopedPDU is discarded without further processing whenever a report PDU is generated. However: - If the operation type can reliably be determined and it is determined to be a Report, SNMPv2-Trap, or a Response then a report PDU is not generated. - A report PDU is only generated when the reportableFlag is set to the value 1. A generated report PDU must always use the current values of snmpEngineID, engineBoots, and engineTime from the LCD. In addition, a generated report PDU must contain the same msgID value as in the received message. -- Editor's note: Sounds on the mailing list that we need to allow access control checking for Notifications that must be generated by the F-Ts. Once the decision is made we can add text here. -- End Editor's note Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 10] Draft Local Processing Model (LPM) for SNMPv3 May 1997 4. Definitions SNMPV3-LP-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Unsigned32, MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION, TestAndIncr, RowStatus, AutonomousType, StorageType, TDomain, TAddress FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF, SnmpV3GroupName, SnmpV3ContextName, SnmpV3LoS, SnmpV3EngineID, SnmpV3SecurityModel FROM SNMPv3-MIB; snmpV3LpMIB MODULE-IDENTITY LAST-UPDATED "9705090000Z" -- 09 May 1997, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@tis.com Subscribe: majordomo@tis.com In msg body: subscribe snmpv3 Chair: Russ Mundy Trutsed Information Systems postal: 3060 Washington Rd Glenwood MD 21738 email: mundy@tis.com phone: 301-854-6889 Co-editor: Bert Wijnen IBM T.J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-412-498 Co-editor Dave Harrington Cabletron Systems, Inc postal: Post Office Box 5005 MailStop: Durham 35 Industrial Way Rochester NH 03867-5005 email: dbh@cabletron.com phone: 603-337-7357 " DESCRIPTION "The management information definitions for the SNMPv3 Local Processing Model. " Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 11] Draft Local Processing Model (LPM) for SNMPv3 May 1997 ::= { snmpModules xx } -- Administrative assignments **************************************** snmpV3LpMIBObjects OBJECT IDENTIFIER ::= { snmpV3LpMIB 1 } snmpV3LpMIBConformance OBJECT IDENTIFIER ::= { snmpV3LpMIB 2 } -- SNMPv3 Statistics for Local Processing **************************** snmpV3LpStats OBJECT IDENTIFIER ::= { snmpV3LpMIBObjects 1 } snmpV3LpStatsUnknownContexts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv3 engine which were dropped because they referenced a context that was not known to the engine. " ::= { snmpV3LpStats 1 } snmpV3LpStatsUnknownGroups OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv3 engine which were dropped because the security identity mapped onto a group that was not known to the engine (the group has no access at all to the specified context). " ::= { snmpV3LpStats 2 } snmpV3LpStatsUnauthorizedOperations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the SNMPv3 engine which were dropped because the PDU type referred to an operation that is invalid or not authorized. " ::= { snmpV3LpStats 3 } -- Information about Local Contexts ********************************** -- Editor's notes: -- We're still discussing if the contextTable is needed at all -- (See Editor's notes in section 3.1 under item 4). -- For now (May 9) it seems most people want it as a read-only Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 12] Draft Local Processing Model (LPM) for SNMPv3 May 1997 -- table with just one column. -- Others still feel that the context info should be obtained -- from the entityMIB and we should tell that WG to include -- this info. -- End Editor's notes. snmpV3LpContextTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3LpContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of locally available contexts. This table is read-only meaning that SNMP engines in a manager role cannot configure contexts. Instead the table is meant to provide input to SNMP engines in a manager role such that they can properly configure the snmpV3LpAcTable to control access to all contexts in an SNMP engine operating in an agent role. " ::= { snmpV3LpMIBObjects 2 } snmpV3LpContextEntry OBJECT-TYPE SYNTAX SnmpV3LpContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular context." INDEX { IMPLIED snmpV3LpContextName } ::= { snmpV3LpContextTable 1 } SnmpV3LpContextEntry ::= SEQUENCE { snmpV3LpContextName SnmpV3ContextName } snmpV3LpContextName OBJECT-TYPE SYNTAX SnmpV3ContextName MAX-ACCESS read-only STATUS current DESCRIPTION "A textual name uniquely identifying a particular context on a particular agent. " ::= { snmpV3LpContextEntry 1 } -- Information about Access Rights *********************************** snmpV3LpAcTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3LpAcEntry MAX-ACCESS not-accessible STATUS current Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 13] Draft Local Processing Model (LPM) for SNMPv3 May 1997 DESCRIPTION "The table of group access rights configured in the local configuration datastore (LCD). " ::= { snmpV3LpMIBObjects 3 } snmpV3LpAcEntry OBJECT-TYPE SYNTAX SnmpV3LpAcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An access right configured in the local configuration datastore (LCD) authorizing access to a SNMPv3 context. " INDEX { snmpV3LpAcContextName, snmpV3LpAcGroupName, snmpV3LpAcLoS } ::= { snmpV3LpAcTable 1 } SnmpV3LpAcEntry ::= SEQUENCE { snmpV3LpAcContextName SnmpV3ContextName, snmpV3LpAcGroupName SnmpV3GroupName, snmpV3LpAcLoS SnmpV3LoS, snmpV3LpAcReadViewIndex INTEGER, snmpV3LpAcWriteViewIndex INTEGER, snmpV3LpAcStorageType StorageType, snmpV3LpAcStatus RowStatus } snmpV3LpAcContextName OBJECT-TYPE SYNTAX ContextName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The context name which identifies an SNMP context to which this conceptual row grants access rights. " ::= { snmpV3LpAcEntry 1 } snmpV3LpAcGroupName OBJECT-TYPE SYNTAX GroupName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group name which identifies an SNMP group to which this conceptual row grants access rights. " ::= { snmpV3LpAcEntry 1 } snmpV3LpAcLoS OBJECT-TYPE SYNTAX SnmpV3LoS MAX-ACCESS not-accessible Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 14] Draft Local Processing Model (LPM) for SNMPv3 May 1997 STATUS current DESCRIPTION "The minimum level of security required of messages sent on behalf of an identity belonging to the group in order to gain the access rights allowed by this conceptual row. " ::= { snmpV3LpAcEntry 2 } snmpV3LpAcReadViewIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an instance of this object identifies the MIB view of the SNMP context to which this conceptual row authorizes read access. The identified MIB view is that for which snmpV3LpViewIndex has the same value as the instance of this object; if the value is zero or if there is no active MIB view having this value of snmpV3LpViewIndex, then no access is granted. Otherwise, this object is ignored and can take any value at the Local Processing Module's discretion, e.g., zero. Note that read access includes access via retrieval requests as well as transmission of information via notifications. -- Editor's note: Notification stuff still under heavy discussion -- End Editors note " DEFVAL { 0 } ::= { snmpV3LpAcEntry 3 } snmpV3LpAcWriteViewIndex OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of an instance of this object identifies the MIB view of the SNMPv3 context to which this conceptual row authorizes write access. The identified MIB view is that for which snmpV3LpViewIndex has the same value as the instance of this object; if the value is zero or if there is no active MIB view having this value of snmpV3LpViewIndex, then no access is granted. Otherwise, this object is ignored and can take any value at the Local Processing Module's discretion, Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 15] Draft Local Processing Model (LPM) for SNMPv3 May 1997 e.g., zero. " DEFVAL { 0 } ::= { snmpV3LpAcEntry 4 } snmpV3LpAcStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { snmpV3LpAcEntry 5 } snmpV3LpAcStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of snmpV3LpAcStatus for that row. -- Editor's notes: -- We have discussed the removal of the following. That means -- stale entries can occur, and so the agent code will have -- ro be able to deal with it. We're not in agreement yet. -- So we need to discuss at Interim. -- -- A conceptual row in this table is not qualified for -- activation until the context and the group it -- references are active. Further, a conceptual row in -- this table is immediately made notInService whenever -- the status of the context or the group it references -- is made notInService, and immediately destroyed -- whenever the context or the group it references is -- destroyed. -- -- There is also a suggestion as follows (DaveL): -- Why not just have a set of snmpV3LpViewStatus to -- destroy(6) either: -- - fail with an inconsistent value error if any -- corresponding entries exist in the -- snmpV3LpSubtreeFamilyTable, or -- - result also in deletion of all corresponding entries -- in the snmpV3LpSubtreeFamilyTable. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 16] Draft Local Processing Model (LPM) for SNMPv3 May 1997 -- End Editor's notes " ::= { snmpV3LpAcEntry 6 } -- Information about MIB views *************************************** -- Support for views having instance-level granularity is optional snmpV3LpViewTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3LpViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of locally defined MIB views. When an SNMP engine in the manager role wants to create a new MIB view, then it must first create an entry in the snmpV3LpViewTable, using a non-existing index-value for snmpV3LpViewIndex. If the creation of such an entry is successfull, the SNMP engine in the manager role can then start creating entries in the snmpV3LpSubtreeFamiliyTable. When deleting MIB views, it is strongly advised that first the related snmpV3LpSubtreeFamilityEntries are deleted from the snmpV3LpSubtreeFamiliyTable and that only upon completion of that deletion process the snmpV3LpViewEntry is deleted from the snmpV3LpViewTable. Furthermore, a manager should take great care to delete all the "included" family entries before deleting any of the "excluded" ones. Following these procedures there should be no collisions when multiple managers try to update the MIB views at an SNMP engine in an agent role. If managers do not follow these procedures then it is agent-implementation dependent as to what the result of possible collisions will be. " ::= { snmpV3LpMIBObjects 4 } snmpV3LpViewEntry OBJECT-TYPE SYNTAX SnmpV3LpViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular local MIB view." INDEX { snmpV3LpViewIndex } ::= { snmpV3LpViewTable 1 } SnmpV3LpViewEntry ::= SEQUENCE Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 17] Draft Local Processing Model (LPM) for SNMPv3 May 1997 { snmpV3LpViewIndex INTEGER, snmpV3LpViewName OCTET STRING, snmpV3LpViewStorageType StorageType, snmpV3LpViewStatus RowStatus } -- Editor's note There were suggestions to use the viewName as the index instead of the viewIndex. But if we do that, then it seems to me that the search through the viewTable can be quite inefficient. Besides, the majority of the v2adv team agreed that we should use an integer for indexing the views. -- End Editors note. snmpV3LpViewIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary unique value for each MIB view. -- Editor's notes: -- I am not sure I understand why this should stay the -- same. As long as the agent ensures that the mapping -- between the acTable's use of viewIndex and the indices -- in this viewTable are in sync, then it should be OK. -- A manager who wants to add entries to the acTable better -- checks the views before it actually changes the acTable. -- So I plan to remove this text: Once assigned, the value for each MIB view must remain constant for as long as that view is defined, even across re-initializations of the engine's network management system. -- End Editor's notes. Thus, the value for a nonVolatile, permanent, or readOnly (see snmpV3LpViewStorageType) MIB view must either be stored as part of the system's non-volatile configuration information, or be able to be re-generated after each re-initialization. The specific value is meaningful only within a given SNMP engine, i.e., it is not meaningful to any other SNMP engine except to uniquely identify the view within the set of all views known to this SNMP engine. " ::= { snmpV3LpViewEntry 1 } Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 18] Draft Local Processing Model (LPM) for SNMPv3 May 1997 snmpV3LpViewName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "An arbitrary viewName that may help humans recognize the various MIB views. " DEFVAL { "" } ::= { snmpV3LpViewEntry 2 } snmpV3LpViewStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { snmpV3LpViewEntry 3 } snmpV3LpViewStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row." ::= { snmpV3LpViewEntry 4 } -- Subtree families of MIB views ************************************* snmpV3LpSubtreeFamilyTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpV3LpSubtreeFamilyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Locally held information about families of subtrees within MIB views. Each MIB view is defined by two collections of view subtrees: the included view subtrees, and the excluded view subtrees. Every such subtree, both included and excluded, is defined in this table. To determine if a particular object instance is in a particular MIB view, compare the object instance's OBJECT IDENTIFIER with each of the MIB view's active entries in this table. If none match, then the object instance is not in the MIB view. If one or more match, then the object instance is included in, Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 19] Draft Local Processing Model (LPM) for SNMPv3 May 1997 or excluded from, the MIB view according to the value of snmpV3LpSubtreeFamilyType in the entry whose value of snmpV3LpSubtreeFamilySubtree has the most sub-identifiers. If multiple entries match and have the same number of sub-identifiers, then the lexicographically greatest instance of snmpV3LpSubtreeFamilyType determines the inclusion or exclusion. An object instance's OBJECT IDENTIFIER X matches an active entry in this table when the number of sub-identifiers in X is at least as many as in the value of snmpV3LpSubtreeFamilySubtree for the entry, and each sub-identifier in the value of snmpV3LpSubtreeFamilySubtree matches its corresponding sub-identifier in X. Two sub-identifiers match either if the corresponding bit of snmpV3LpSubtreeFamilyMask is zero (the 'wild card' value), or if they are equal. A 'family' of view subtrees is the set of subtrees defined by a particular combination of values of snmpV3LpSubtreeFamilySubtree and snmpV3LpSubtreeFamilyMask. In the case where no 'wild card' is defined in snmpV3LpSubtreeFamilyMask, the family of view subtrees reduces to a single view subtree. When an SNMPv3 engine in the manager role wants to create a new MIB view, then it should first create an entry in the snmpV3LpViewTable, using a non-existing index-value for snmpV3LpViewIndex. If the creation of such an entry is successful, the SNMPv3 engine in the manager role can then start creating entries in the snmpV3LpSubtreeFamiliyTable. When deleting MIB views, it is strongly advised that first the related snmpV3LpSubtreeFamilityEntries are deleted from the snmpV3LpSubtreeFamiliyTable and that only upon completion of that deletion process the snmpV3LpViewEntry is deleted from the snmpV3LpViewTable. Following these procedures there should be no collisions when multiple managers try to update the MIB views at an SNMPv3 engine in an agent role. " ::= { snmpV3LpMIBObjects 5 } snmpV3LpSubtreeFamilyEntry OBJECT-TYPE SYNTAX SnmpV3LpSubtreeFamilyEntry Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 20] Draft Local Processing Model (LPM) for SNMPv3 May 1997 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular family of view subtrees included in or excluded from a particular SNMPv3 context's MIB view. The MIB view must exist (i.e., be represented by a conceptual row in the snmpV3LpViewTable) before any subtree families can be defined for it. Implementations must not restrict the number of families of view subtrees for a given MIB view, except as dictated by resource constraints on the overall number of entries in the snmpV3LpSubtreeFamilyTable. The value of snmpV3LpViewIndex in this INDEX clause of this table identifies the MIB view in which this subtree family exists. A MIB view for which there are no conceptual rows in this table is the empty set of view subtrees. " INDEX { snmpV3LpViewIndex, IMPLIED snmpV3LpSubtreeFamilySubtree } ::= { snmpV3LpSubtreeFamilyTable 1 } SnmpV3LpSubtreeFamilyEntry ::= SEQUENCE { snmpV3LpSubtreeFamilySubtree OBJECT IDENTIFIER, snmpV3LpSubtreeFamilyMask OCTET STRING, snmpV3LpSubtreeFamilyType INTEGER, snmpV3LpSubtreeFamilyStorageType StorageType, snmpV3LpSubtreeFamilyStatus RowStatus } snmpV3LpSubtreeFamilySubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MIB subtree which when combined with the corresponding instance of snmpV3LpSubtreeFamilyMask defines a family of view subtrees. " ::= { snmpV3LpSubtreeFamilyEntry 1 } snmpV3LpSubtreeFamilyMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The bit mask which, Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 21] Draft Local Processing Model (LPM) for SNMPv3 May 1997 in combination with the corresponding instance of snmpV3LpSubtreeFamilySubtree, defines a family of view subtrees. Each bit of this bit mask corresponds to a sub-identifier of snmpV3LpSubtreeFamilySubtree, with the most significant bit of the i-th octet of this octet string value (extended if necessary, see below) corresponding to the (8*i - 7)-th sub-identifier, and the least significant bit of the i-th octet of this octet string corresponding to the (8*i)-th sub-identifier, where i is in the range 1 through 16. Each bit of this bit mask specifies whether or not the corresponding sub-identifiers must match when determining if an OBJECT IDENTIFIER is in this family of view subtrees; a '1' indicates that an exact match must occur; a '0' indicates 'wild card', i.e., any sub-identifier value matches. Thus, the OBJECT IDENTIFIER X of an object instance is contained in a family of view subtrees if, for each sub-identifier of the value of snmpV3LpSubtreeFamilySubtree, either: the i-th bit of snmpV3LpSubtreeFamilyMask is 0, or the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of snmpV3LpSubtreeFamilySubtree. If the value of this bit mask is M bits long and there are more than M sub-identifiers in the corresponding instance of snmpV3LpSubtreeFamilySubtree, then the bit mask is extended with 1's to be the required length. Note that when the value of this object is the zero-length string, this extension rule results in a mask of all-1's being used (i.e., no 'wild card'), and the family of view subtrees is the one view subtree uniquely identified by the corresponding instance of snmpV3LpSubtreeFamilySubtree. " DEFVAL { ''H } ::= { snmpV3LpSubtreeFamilyEntry 2 } snmpV3LpSubtreeFamilyType OBJECT-TYPE SYNTAX INTEGER { included(1), excluded(2) } MAX-ACCESS read-create Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 22] Draft Local Processing Model (LPM) for SNMPv3 May 1997 STATUS current DESCRIPTION "The indication of whether the corresponding instances of snmpV3LpSubtreeFamilySubtree and snmpV3LpSubtreeFamilyMask define a family of view subtrees which is included in or excluded from the MIB view. " DEFVAL { included } ::= { snmpV3LpSubtreeFamilyEntry 3 } snmpV3LpSubtreeFamilyStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. -- Editor's notes: -- There is the suggestion from DaveL to let these rows -- inherit the StorageType from the corresponding entries -- in the viewTable as the default StorageType. -- End Editor's notes: " DEFVAL { nonVolatile } ::= { snmpV3LpSubtreeFamilyEntry 4 } snmpV3LpSubtreeFamilyStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. For those columnar objects which permit write-access, their value in an existing conceptual row can be changed irrespective of the value of snmpV3LpSubtreeFamilyStatus for that row. A conceptual row in this table is not qualified for activation until the MIB view it references is active. Further, a conceptual row in this table is immediately made notInService whenever the status of the view it references is made notInService, and immediately destroyed whenever the view it references is destroyed. " ::= { snmpV3LpSubtreeFamilyEntry 4 } -- Conformance information ******************************************* Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 23] Draft Local Processing Model (LPM) for SNMPv3 May 1997 snmpV3LpMIBCompliances OBJECT IDENTIFIER ::= { snmpV3LpMIBConformance 1 } snmpV3LpMIBGroups OBJECT IDENTIFIER ::= { snmpV3LpMIBConformance 2 } -- Compliance statements ********************************************* snmpV3LpMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv3 entities which implement the SNMPv3 LPM remote configuration MIB. " MODULE -- this module MANDATORY-GROUPS { snmpV3LpBasicGroup } OBJECT snmpV3LpViewStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3LpViewStatus MIN-ACCESS read-only DESCRIPTION "Create access to the snmpV3LpViewTable is not required. " OBJECT snmpV3LpSubtreeFamilyMask WRITE-SYNTAX OCTET STRING (SIZE (0)) MIN-ACCESS read-only DESCRIPTION "Support for configuration via SNMPv3 of subtree families defined using wild-cards is not required. " OBJECT snmpV3LpSubtreeFamilyStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpV3LpSubtreeFamilyStatus MIN-ACCESS read-only DESCRIPTION "Create access to the snmpV3LpSubtreeFamilyTable is not required. " ::= { snmpV3LpMIBCompliances 1 } -- Units of conformance ********************************************** snmpV3LpBasicGroup OBJECT-GROUP OBJECTS { snmpV3LpContextStatus, snmpV3LpAcReadViewIndex, snmpV3LpAcWriteViewIndex, Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 24] Draft Local Processing Model (LPM) for SNMPv3 May 1997 snmpV3LpAcStorageType, snmpV3LpAcStatus, snmpV3LpViewStorageType, snmpV3LpViewStatus, snmpV3LpSubtreeFamilyMask, snmpV3LpSubtreeFamilyType, snmpV3LpSubtreeFamilyStorageType, -- length 32 !! snmpV3LpSubtreeFamilyStatus } STATUS current DESCRIPTION "A collection of objects providing for remote configuration of an SNMPv3 engine which implements the SNMPv3 Local Processing Model (LPM). " ::= { snmpV3LpMIBGroups 1 } END Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 25] Draft Local Processing Model (LPM) for SNMPv3 May 1997 5. Security Considerations 5.1 Recommended Practices This document is meant for use in the SNMPng architecture. The Local Processing Model (LPM) described in this document controls access rights to management information based on: - contextName, representing a set of management information at the managed system where the Local Processing module is running. - groupName, representing a group or set of zero, one or more security entities. These security entities are mapped into one or more groups in the SNMPv3 Security subsystem. - Level of Security (LoS) used for the transmission of an SNMP message. When the Local Processing module (LPM) is called for processing a scopedPDU, it is assumed that the Message Processing and Control module (MPC) has ensured the authentication and privacy aspects as specified by the Level of security (LoS) that is being passed. 5.2 Defining Groups GroupNames are used to give access to a group of zero, one or more security entities. Within the LPM, a groupName is considered to exist if that groupName is used (as an index) in a row in the snmpV3LpAcTable. By mapping a security identity into a group, a Security subsystem can add/delete entities to a group. 5.3 Conformance Conformance rules are described in the SNMPng architecture document [SNMPng-ARCH]. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 26] Draft Local Processing Model (LPM) for SNMPv3 May 1997 6. Editor's Addresses Co-editor: Bert Wijnen IBM T. J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-432-794 Co-editor: Randy Presuhn BMC Software, Inc postal: 1190 Saratoga Avenue, Suite 130 San Jose, CA 95129-3433 USA email: rpresuhn@bmc.com phone: +1-408-556-0720 Co-editor: Keith McCloghrie Cisco Systems, Inc. postal: 170 West Tasman Drive San Jose, CA 95134-1706 USA email: kzm@cisco.com phone: +1-408-526-5260 7. Acknowledgements This document describes the work of the SNMP Security and Administrative Framework Evolution team, comprised of David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research) Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 27] Draft Local Processing Model (LPM) for SNMPv3 May 1997 8. References [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S., Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 January 1996. [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [SNMPng-ARCH] The SNMPng Working Group, Harrington, D., Wijnen, B., "Architectural Model for the Next Generation Simple Network Managememt Protocol (SNMPng)", draft-ietf-snmpng-arch-00.txt, March 1997. [SNMPv3-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D., "Local Processing Model for the Next Generation Simple Network Management Protocol (SNMPng)", draft-ietf-snmpng-lpm-00.txt, March 1997. [SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D., "Message Processing and Control Model for version 3 of the Simple Network Management Protocol (SNMPv3)", draft-ietf-snmpv3-mpc-00.txt, March 1997. [SNMPv3-USEC] To be written The SNMPng Working Group, Editors...Names, "The User-Based Security Model for the Next Generation Simple Network Management Protocol (SNMPng)", draft-ietf-snmpng-usec-00.txt, April 1997. Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 28] Draft Local Processing Model (LPM) for SNMPv3 May 1997 APPENDIX A - Installation A.1. Agent Installation Parameters During installation, an SNMPv3 engine acting in an authoritative role is configured with several parameters. These include for the Local Processing module: (1) A security posture The choice of security posture determines the extent of the view configured for unauthenticated access. One of three possible choices is selected: minimum-secure, semi-secure, or very-secure. (2) A default context One entry in the snmpV3LpContextTable as with a contextName of "" (the empty string, representing the default context. (3) Three entries in the snmpV3LpAcTable as follows: - One entry to be used for unauthenticated access: no privacy support privacy support ------------------ --------------- snmpV3LpAcContextName "" "" snmpV3LpAcGroupName "public" "public" snmpV3LpAcLoS noAuth/noPriv noAuth/noPriv snmpV3LpAcReadViewIndex 1 1 snmpV3LpAcWriteViewIndex 0 0 snmpV3LpStorageType permanent permanent snmpV3LpStatus active active - One entry to be used for authenticated access but without privacy: no privacy support privacy support ------------------ --------------- snmpV3LpAcContextName "" "" snmpV3LpAcGroupName "public" "public" snmpV3LpAcLoS Auth/noPriv Auth/noPriv snmpV3LpAcReadViewIndex 2 2 snmpV3LpAcWriteViewIndex 2 2 snmpV3LpStorageType permanent permanent snmpV3LpStatus active active - One entry to be used for authenticated access with privacy: Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 29] Draft Local Processing Model (LPM) for SNMPv3 May 1997 no privacy support privacy support ------------------ --------------- snmpV3LpAcContextName "" snmpV3LpAcGroupName "public" snmpV3LpAcLoS Auth/Priv snmpV3LpAcReadViewIndex 2 snmpV3LpAcWriteViewIndex 2 snmpV3LpStorageType permanent snmpV3LpStatus active (4) Two views depending on the security posture. - One view (the view) for authenticated access: - the MIB view is the following subtree: "internet" [RFC1902] - A second view (the view) for unauthenticated access. This view is configured according to the selected security posture: - For the "very-secure" posture: the MIB view is the union of these subtrees: "snmp" [RFC1907] "snmpEngine" [SNMPv3-USEC] "usecStats" [SNMPv3-USEC] "authMD5Stats" [SNMPv3-USEC] "privDESStats" [SNMPv3-USEC] "snmpV3Stats" [SNMPv3-MPC] "snmpV3LpStats" [SNMPv3-LPM] - For the "semi-secure" posture: the MIB view is the union of these subtrees: "snmp" [RFC1907] "snmpEngine" [SNMPv3-USEC] "usecStats" [SNMPv3-USEC] "authMD5Stats" [SNMPv3-USEC] "privDESStats" [SNMPv3-USEC] "snmpV3Stats" [SNMPv3-MPC] "snmpV3LpStats" [SNMPv3-LPM] "system" [RFC1907] - For the "minimum-secure" posture: the MIB view is the following subtree. "internet" [RFC1902] - Access rights to allow: Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 30] Draft Local Processing Model (LPM) for SNMPv3 May 1997 - read-only access for LoS "noAuth" on behalf of security entities that belong to the group "public" to the MIB view in the context with contextName "". - read-write access for LoS "auth" on behalf of security entities that belong to the group "public" to the MIB view in the context with contextName "". - if privacy is supported, read-write access for LoS "auth" on behalf of security entities that belong to the group "public" to the MIB view in the context with contextName "". -- Editor's note: If we find it useful (I do) then I will also work out the entries in the viewTable and viewSubtreeFamilyTable so that we have the above views defined. -- End Editor's note Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 31] Draft Local Processing Model (LPM) for SNMPv3 May 1997 Table of Contents 0. Issues 2 0.1 Change Log 2 1. Introduction 3 1.2 Local Processing 3 1.3 Local Configuration Datastore 4 2. Elements of the Model 5 2.1 Groups 5 2.2 Level of Security (LoS) 5 2.3 Contexts 5 2.4 scopedPDU 5 2.5 Access Policy 6 2.6. Error Reporting 6 3. Elements of Procedure 8 3.1 Processing a Received scopedPDU 8 3.1.1. Additional Details 10 3.1.1.1. ASN.1 Parsing Errors 10 3.1.1.2. Generation of a Report PDU 10 4. Definitions 11 5. Security Considerations 26 5.1 Recommended Practices 26 5.2 Defining Groups 26 5.3 Conformance 26 6. Editor's Addresses 27 7. Acknowledgements 27 8. References 28 A.1. Agent Installation Parameters 29 Wijnen/Presuhn/McCloghrie Expires November 1997 [Page 32]