Local Processing Model for the Next Generation Simple Network Management Protocol (SNMPng) 26 March 1997 B. Wijnen IBM T.J. Watson Research wijnen@vnet.ibm.com D. Harrington Cabletron Systems, Inc. dbh@cabletron.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 the Next-Generation of the Simple Network Management Protocol (SNMPng). It is part of the overall Architectural Model for the Next Generation Simple Network Management Protocol (SNMPng). This document includes a MIB for remotely monitoring/managing the configuration paramters for this LPM. Wijnen/Harrington Expires September 1977 [Page 1] Draft Local Processing Model (LPM) for SNMPng March 1997 0. Change Log [version 0.6] - Add address info for WG chair. - Add address for DaveH in MIB description - submit as I-D [version 0.5] - Some more comments by BW. - Some more cleanup - Address comments from others (dbh, dl) - complete missing sections - I still have quite a few of editor's notes so that people can discuss/evaluate the alternatives. Or do we want/need to take a position right now? - add abstract - prepare for pagination [version 0.4] - Add initial config info as appendix A - Some more cleanup [version 0.3] - Explain and extend usage of viewTable and subtreeFamilyTable [version 0.2] - merge in dbh comments - add more personal bw comments - add more terminology definitions - add MIB [version 0.1] - initial version Wijnen/Harrington Expires September 1977 [Page 2] Draft Local Processing Model (LPM) for SNMPng March 1997 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. 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. Operations of the protocol are carried out under an administrative framework which defines minimum policies for mechanisms which provide message-level security, access control for managed objects, and interaction between the protocol engine and the applications which use the services of the engine. The Architectural Model for SNMPng [SNMPng-ARCH] describes a Local Processing Framework for SNMP messages that are targetted for local processing to access management information or for SNMP messages that originate from local processing of management information. It is the purpose of this document to define a Local Processing Model (LP-M) for the Next Generation Simple Network Management Protocol (LP-M for SNMPng). 1.1 Terminology Definition of SNMPng acronyms and terms: MPC-F - Message Processing and Control Framework MPC-M - Message Processing and Control Model MPC-I - Message Processing and Control Implementation SF-F - Security Framework SF-M - Security Framework Model SF-I - Security Framework Implementation LP-F - Local Processing Framework LP-M - Local Processing Model LP-I - Local Processing Implementation LCD - Local Configuration Datastore 1.2 Local Processing Local Processing may occur in an SNMPng entity acting in an agent role in response to SNMPng request messages from an SNMPng Wijnen/Harrington Expires September 1977 [Page 3] Draft Local Processing Model (LPM) for SNMPng March 1997 entity acting in a manager role. These request messages include several types of operations, including GetRequest, GetNextRequest, GetBulkRequest, and SetRequest operations. Local Processing only occurs if the request is targeted at local management information as determined by the contextID in the Naming-Scope in a Scoped-PDU. It is the MPC implementation (MPC-I) that determines if the contextID refers to the current SNMPng engine and if so, to direct the Scoped-PDU to the LP-I. 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 error report, termed the Report-PDU. Local Processing is also responsible for generating notifications, which will result in the production of one or more traps, termed SNMPv2-TRAP-PDUs. 1.3 Local Configuration Datastore To implement the model described in this document, each SNMPng entity needs to retain its own set of information about access rights and policies, trap destinations, and the like. This set of information is called the SNMPng entity's Local Configuration Datastore (LCD) because it is locally-stored information. In order to allow an SNMPng entity's LCD to be remotely configured, portions of the LCD need to be accessible as managed objects. A MIB module, the SNMPng LP-M Configuration MIB, which defines these managed object types is included in this document. Wijnen/Harrington Expires September 1977 [Page 4] Draft Local Processing Model (LPM) for SNMPng March 1997 2. Elements of the Model This section contains definitions to realize the access control applied by this LP-M. 2.1 SNMPng Group A groupName identifies a group (set) of zero or more security entities on whose behalf SNMP messages are being processed or generated. It is the responsibility of the MPC-I to determine in an authorirative manner for which groupName an incoming SNMP message is being processed. It is the responsibility of the LP-I to determine the groupName for which a notification (TRAP) is being generated. This Model (LP-M) requires the groupName to be passed as input to an implementation (LP-I) of this LP-M when a message is handed to the LP-I for processing. This Model (LP-M) requires the groupName to be passed as output from an implementation (LP-I) when a message originates from the LP-I. 2.2 SNMPng Quality of Service (Qos) The Qos identifies the Quality of Service (in terms of message security) used for transmitting the SNMP message. It is the responsibility of the MPC-I to determine in an authoritative manner the Qos that was used for an incoming SNMP message. It is the responsibility of the LP-I to determine the Qos that must be used when transmitting a notification (TRAP). This Model (LP-M) recognizes three different Qos levels: - without authentication and without privacy - with authentication but without privacy - with authentication and with privacy This Model (LP-M) requires the Qos to be passed as input to an implementation (LP-I) of this LP-M when a message is handed to the LP-I for processing. This Model (LP-M) requires the Qos to be passed as output from an implementation (LP-I) when a message originates from the LP-I. 2.3 Contexts Wijnen/Harrington Expires September 1977 [Page 5] Draft Local Processing Model (LPM) for SNMPng March 1997 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 SNMPng Scoped-PDU A scoped-PDU contains a Naming-Scope that unambiguously identifies an SNMP agent and the context, (locally) accesible by that agent, to which the SNMP management information in the SNMP-PDU refers. A Naming-Scope contains a contextID that unambiguously identifies the SNMP agent which has (local) access to the management information refered 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 or from which the SNMP-PDU is originated. It is the responsibility of the MPC-I to determine in an authoritative manner if the contextID refers to the current SNMPng engine and if so to direct the SNMP message to the LP-I for local processing. It is the responsibility of the LP-I to determine the contextName from which the management information in a notification (TRAP) is retrieved. This Model (LP-M) requires the Soped-PDU to be passed as input to an implementation (LP-I) of this LP-M if a message is handed to the LP-I for processing. This Model (LP-M) requires that the contextName be passed as input to an implementation (LP-I) of this LP-M if a trap must be generated. This Model (LP-M) requires the Soped-PDU to be passed as output from an implementation (LP-I) if a message originates from the LP-I. Editor's notes: I wonder if it would not be better to not use a Scoped-PDU as input/output to the LP-M but instead use contextName plus PDU as input/output. After all, the contextID is irrelevant in the LP-M and is in fact only used/known in the MPC. End Editor's notes. Wijnen/Harrington Expires September 1977 [Page 6] Draft Local Processing Model (LPM) for SNMPng March 1997 2.5 Access Policy The access policy of this LP-M 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 Qos, 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-M and SF-M End Editor's notes. While processing a received communication, an SNMPng entity may determine that the message is unacceptable. In this case, the appropriate error counter is incremented and the received message is discarded without further processing. If an SNMPng entity 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 LP-I, the Qos for sending the report-PDU is set to noAUth (no authentiocation, no privacy). The reportableFlag should never be set for a message that contains a Response, SNMPv2-Trap or Report operation. Wijnen/Harrington Expires September 1977 [Page 7] Draft Local Processing Model (LPM) for SNMPng March 1997 3. Elements of Procedure This section describes the procedures followed by an implementation (LP-I) of this Model (LP-M) when processing or generating a Scoped-PDU 3.1 Processing a Received Scoped-PDU This section describes the procedure followed by an implementation (LP-I) whenever it receives a scoped-PDU for local processing. This procedure is independent of any of the other processing within the SNMPng Architectural Model. (1) The PDU portion of the Scoped-PDU 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 scoped-PDU is discarded without further processing. (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 Report, Response, Trap, or Inform operation, then the snmpNgLpmStatsUnauthorizedOperations counter is incremented, and the received Scoped-PDU is discarded without further processing. Editor's notes: the above PDU-types should not be passed to the LP-I. So it seems that the MPC-M also must define some SNMP PDU processing for Report, Response, Trap, Inform. We used UnauthorizedOperations counter in v2u but v2* used authorizationError (in SNMP PDU)... The v2u did that because it was part of the access-control as opposed to part of PDU processing. Now it seems part of PDU processing again... so maybe using authorizationError is OK again... that is if we get to this point. If the MPC-I detects it, then it should be an unauthorizedOperations-report I think. End Editor's notes. (4) The LCD is consulted for information about the SNMPng context identified by the contextName. If information about this SNMPng context is absent from the LCD, then the snmpNgLpmStatsUnknownContexts counter is incremented, a report PDU [RFC1905] is generated, and the received scoped-PDU is discarded without further processing. Wijnen/Harrington Expires September 1977 [Page 8] Draft Local Processing Model (LPM) for SNMPng March 1997 Editor's notes: The above means we have a contextTable within LPM, but I am not sure we need one... since we just use a contextName as an index into the snmpNgLpmAcTable. We already decided to get rid of contextLocalEntity. I have heard many stories that contectLocalTime is not used and that the functionality could be achieved by just defining few extra objects for those that need something like a value to be used at restartTime. If we do not use a contextTable, then we could check that the context is used as index in the acTable and if not, then we assume the context does not exist An other alternative is to skip step (4) and (5) and just return an authorizationError or a reportPDU for snmpNgLpmUnAuthorizedOperations since we will not find an entry in the snmpNgLpmAcTable. Some feel that the contextTable must exist (that is in readOnly mode) so that a manager can learn about the contextNames that exist at an agent. But the entityMIB also sort of defines logical entities which basically map to contextNames. However, the current entityMIB does not yet address SNMPng contexts. Maybe we should sync up with them. End Editor's notes. (5) The LCD is consulted for information about the SNMPng group identified by the groupName. If information about this SNMPng group is absent from the LCD, then the snmpNgLpmStatsUnknownGroups counter is incremented, a report PDU [RFC1905] is generated, and the received Scoped-PDU is discarded without further processing. Editor's notes: The above would assume that we just check if the group is used as an index in the snmpNgLpmAcTable at all An other alternative is to skip step (4) and (5) and just return a authorizationError or a reportPDU for snmpNgLpmUnAuthorizedOperations since we will not find an entry in the snmpNgLpmAcTable. End Editor's notes. (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 Qos, on behalf of the indicated group, and concerning management information in Wijnen/Harrington Expires September 1977 [Page 9] Draft Local Processing Model (LPM) for SNMPng March 1997 the indicated context for the particular SNMPv2 operation type. b) if the SNMPv2 operation type is not among the authorized access rights, then the snmpNgLpmStatsUnauthorizedOperations counter is incremented, a report PDU is generated, and the received Scoped-PDU is discarded without further processing. c) the management operation represented by the SNMPv2 operation type is performed by the receiving LP-I with respect to the relevant MIB view within the SNMPng context according to the procedures set forth in [RFC1905], where the relevant MIB view is determined according to the contextName, groupName and the Qos values and the SNMPv2 operation type requested. d) An SNMPv2 Response-PDU is produced and presented to the the MPC-I for further processing. The LP-I uses the scoped-PDU-MMS to ensure that the produced Response-PDU does not exceed the maximum message size. 3.2 Generating a Notification This section describes the procedure followed by an implementation (LP-I) whenever it must generate a Scoped-PDU for an SNMPv2-Trap. This procedure is independent of any of the other processing within the SNMPng Architectural Model. (1) The LCD is consulted for the set of trap destinations. (2) For each element in the set of trap destinations, the Qos, group (snmpNgLpmTrapGroup), destination addres and security model (snmpNgLpmSecModel) are extracted from the LCD and used together with the contextName in the following steps: a) the LCD is consulted for access rights authorized for communications using the indicated Qos, on behalf of the indicated group, and concerning management information in the indicated context for the SNMPv2 trap operation. b) if the SNMPv2 trap operation is not among the authorized access rights, then no SNMPv2-TRAP PDU is produced and processing continues with the next element. c) the varBindList is checked against the relevant MIB view where the relevant MIB view is determined according to the contextName, groupName and the Qos values and the SNMPv2 trap operation. Wijnen/Harrington Expires September 1977 [Page 10] Draft Local Processing Model (LPM) for SNMPng March 1997 d) if any varBind is not in view, then no SNMPv2-TRAP PDU is produced and processing continues with the next element. e) an SNMPv2-TRAP PDU is produced and presented to the MPC-I for further processing. The LP-I passes the the Scoped-PDU, security model, the Qos, the groupName and the destination address to the MPC-I. Wijnen/Harrington Expires September 1977 [Page 11] Draft Local Processing Model (LPM) for SNMPng March 1997 4. Definitions SNMPng-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, SnmpNgGroupName, SnmpNgContextName, SnmpNgQos, SnmpNgEngineID, SnmpNgSecurityModel FROM SNMPng-MIB; snmpNgLpMIB MODULE-IDENTITY LAST-UPDATED "9703260000Z" -- 26 Mar 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 SNMPng Local Processing Model. " Wijnen/Harrington Expires September 1977 [Page 12] Draft Local Processing Model (LPM) for SNMPng March 1997 ::= { snmpModules xx } -- Administrative assigments ***************************************** snmpNgLpMIBObjects OBJECT IDENTIFIER ::= { snmpNgLpMIB 1 } snmpNgLpMIBConformance OBJECT IDENTIFIER ::= { snmpNgLpMIB 2 } -- Information about Local Contexts ********************************** -- Editor's notes: -- We're still discussing if the contextTable is needed at all -- See Edotor's notes in section 3.1 under item 4). -- End Editor's notes. snmpNgLpContextTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpNgLpContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of locally available contexts. This table is read-only meaning that SNMPng entities in a manager role cannot configure contexts. Instead the table is meant to provide input to SNMPng entities in a manager role sich that they can properly configure the snmpNgLpAcTable to control access to all contexts in an SNMPng entity operating in an agent role. " ::= { snmpNgLpMIBObjects 1 } snmpNgLpContextEntry OBJECT-TYPE SYNTAX SnmpNgLpContextEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular context." INDEX { IMPLIED snmpNgLpContextName } ::= { snmpNgLpContextTable 1 } SnmpNgLpContextEntry ::= SEQUENCE { snmpNgLpContextName SnmpNgContextName, snmpNgLpContextStatus RowStatus } snmpNgLpContextName OBJECT-TYPE SYNTAX SnmpNgContextName MAX-ACCESS not-accessible STATUS current DESCRIPTION "A textual name uniquely identifying a particular context on a particular agent. Wijnen/Harrington Expires September 1977 [Page 13] Draft Local Processing Model (LPM) for SNMPng March 1997 " ::= { snmpNgLpContextEntry 1 } snmpNgLpContextStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The status of this conceptual row in the context table. " ::= { snmpNgLpContextEntry 2 } -- Information about Access Rights *********************************** snmpNgLpAcTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpNgLpAcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of group access rights configured in the local configuration datastore (LCD). " ::= { snmpNgLpMIBObjects 2 } snmpNgLpAcEntry OBJECT-TYPE SYNTAX SnmpNgLpAcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An access right configured in the local configuration datastore (LCD) authorizing access to a SNMPng context. " INDEX { snmpNgLpAcContextName, snmpNgLpAcGroupName, snmpNgLpAcQoS } ::= { snmpNgLpAcTable 1 } SnmpNgLpAcEntry ::= SEQUENCE { snmpNgLpAcContextName SnmpNgContextName, snmpNgLpAcGroupName SnmpNgGroupName, snmpNgLpAcPrivileges INTEGER, snmpNgLpAcReadViewIndex INTEGER, snmpNgLpAcWriteViewIndex INTEGER, snmpNgLpAcStorageType StorageType, snmpNgLpAcStatus RowStatus } snmpNgLpAcContextName OBJECT-TYPE SYNTAX ContextName Wijnen/Harrington Expires September 1977 [Page 14] Draft Local Processing Model (LPM) for SNMPng March 1997 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The context name which identifies an SNMPng context to which this conceptual row grants access rights. " ::= { snmpNgLpAcEntry 1 } snmpNgLpAcGroupName OBJECT-TYPE SYNTAX GroupName MAX-ACCESS not-accessible STATUS current DESCRIPTION "The group name which identifies an SNMPng group to which this conceptual row grants access rights. " ::= { snmpNgLpAcEntry 1 } snmpNgLpAcQoS OBJECT-TYPE SYNTAX QoS MAX-ACCESS not-accessible STATUS current DESCRIPTION "The minimum level of security required of messages sent on behalf of an entity belonging to the group in order to gain the access rights allowed by this conceptual row. " ::= { snmpNgLpAcEntry 2 } snmpNgLpAcPrivileges OBJECT-TYPE SYNTAX BITS { get(0), getNext(1), getBulk(2), set(3), inform(4), snmpv2Trap(5) } -- Editor's notes: -- I think we should remove inform... it is not handled in -- the LP-M. Inform is application to application. -- I also have no problem if we were to use SNMPv2* -- values: nothing(1), readOnly(2), readWrite(3) -- -- There is also the suggestion to do away with this column -- all together because the Privileges can be detrmined -- based on the readView or writeView being non-zero. -- End Editor's notes. MAX-ACCESS read-create STATUS current DESCRIPTION "The access privileges authorized by this conceptual row. Access privileges specify whether received retrieval and modification requests are permitted to be processed, and whether notifications are permitted to be transmitted. A type of request is authorized if and only if the corresponding enumerated bit is set. " Wijnen/Harrington Expires September 1977 [Page 15] Draft Local Processing Model (LPM) for SNMPng March 1997 DEFVAL { { get, getNext, getBulk } } ::= { snmpNgLpAcEntry 3 } snmpNgLpAcReadViewIndex 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 SNMPng context to which this conceptual row authorizes read access. The identified MIB view is that for which snmpNgLpViewIndex has the same value as the instance of this object; if the value is zero or there is no MIB view having this value of snmpNgLpViewIndex, 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 (traps). " DEFVAL { 0 } ::= { snmpNgLpAcEntry 4 } snmpNgLpAcWriteViewIndex 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 SNMPng context to which this conceptual row authorizes write access. The identified MIB view is that for which snmpNgLpViewIndex has the same value as the instance of this object; if the value is zero or there is no MIB view having this value of snmpNgLpViewIndex, 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. " DEFVAL { 0 } ::= { snmpNgLpAcEntry 5 } snmpNgLpAcStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create Wijnen/Harrington Expires September 1977 [Page 16] Draft Local Processing Model (LPM) for SNMPng March 1997 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 } ::= { snmpNgLpAcEntry 6 } snmpNgLpAcStatus 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 snmpNgLpAcStatus for that row. -- Editor's notes: -- I am planning to remove the following based on discussions -- in Montreal between Shawn, JeffJohnson and ourselves -- where they claimed we should just allow for stale entries. -- -- 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 snmpNgLpViewStatus to -- destroy(6) either: -- - fail with an inconsistent value error if any -- corresponding entries exist in the -- snmpNgLpSubtreeFamilyTable, or -- - result also in deletion of all corresponding entries -- in the snmpNgLpSubtreeFamilyTable. -- End Editor's notes " ::= { snmpNgLpAcEntry 7 } -- Information about MIB views *************************************** -- Support for views having instance-level granularity is optional snmpNgLpViewTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpNgLpViewEntry Wijnen/Harrington Expires September 1977 [Page 17] Draft Local Processing Model (LPM) for SNMPng March 1997 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of locally defined MIB views. When an SNMPng entity in the manager role wants to create a new MIB view, then it must first create an entry in the snmpNgLpViewTable, using a non-existing index-value for snmpNgLpViewIndex. If the creation of such an entry is successfull, the SNMPng entity in the manager role can then start creating entries in the snmpNgLpSubtreeFamiliyTable. When deleting MIB views, it is stronly advised that first the related snmpNgLpSubtreeFamilityEntries are deleted from the snmpNgLpSubtreeFamiliyTable and that only upon completion of that deletion process the snmpNgLpViewEntry is deleted from the snmpNgLpViewTable. Following these procedures there should be no collisions when multiple managers try to update the MIB views at an SNMPng entity in an agent role. " ::= { snmpNgLpMIBObjects 3 } snmpNgLpViewEntry OBJECT-TYPE SYNTAX SnmpNgLpViewEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular local MIB view." INDEX { snmpNgLpViewIndex } ::= { snmpNgLpViewTable 1 } SnmpNgLpViewEntry ::= SEQUENCE { snmpNgLpViewIndex INTEGER, snmpNgLpViewName OCTET STRING, snmpNgLpViewStorageType StorageType, snmpNgLpViewStatus RowStatus } snmpNgLpViewIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary unique value for each MIB view. 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 entity's network management system. Wijnen/Harrington Expires September 1977 [Page 18] Draft Local Processing Model (LPM) for SNMPng March 1997 -- 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. -- End Editor's notes. Thus, the value for a nonVolatile, permanent, or readOnly (see snmpNgLpViewStorageType) 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 SNMPng entity, i.e., it is not meaningful to any other SNMPng entity except to uniquely identify the view within the set of all views known to this SNMPng entity. " ::= { snmpNgLpViewEntry 1 } snmpNgLpViewName 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 { "" } ::= { snmpNgLpViewEntry 2 } snmpNgLpViewStorageType 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 } ::= { snmpNgLpViewEntry 3 } snmpNgLpViewStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row." Wijnen/Harrington Expires September 1977 [Page 19] Draft Local Processing Model (LPM) for SNMPng March 1997 ::= { snmpNgLpViewEntry 4 } -- Subtree families of MIB views ************************************* snmpNgLpSubtreeFamilyTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpNgLpSubtreeFamilyEntry 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, or excluded from, the MIB view according to the value of snmpNgLpSubtreeFamilyType in the entry whose value of snmpNgLpSubtreeFamilySubtree has the most sub-identifiers. If multiple entries match and have the same number of sub-identifiers, then the lexicographically greatest instance of snmpNgLpSubtreeFamilyType 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 snmpNgLpSubtreeFamilySubtree for the entry, and each sub-identifier in the value of snmpNgLpSubtreeFamilySubtree matches its corresponding sub-identifier in X. Two sub-identifiers match either if the corresponding bit of snmpNgLpSubtreeFamilyMask 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 snmpNgLpSubtreeFamilySubtree and snmpNgLpSubtreeFamilyMask. In the case where no 'wild card' is defined in snmpNgLpSubtreeFamilyMask, the family of view subtrees reduces to a single view subtree. Wijnen/Harrington Expires September 1977 [Page 20] Draft Local Processing Model (LPM) for SNMPng March 1997 When an SNMPng entity in the manager role wants to create a new MIB view, then it must first create an entry in the snmpNgLpViewTable, using a non-existing index-value for snmpNgLpViewIndex. If the creation of such an entry is successfull, the SNMPng entity in the manager role can then start creating entries in the snmpNgLpSubtreeFamiliyTable. When deleting MIB views, it is stronly advised that first the related snmpNgLpSubtreeFamilityEntries are deleted from the snmpNgLpSubtreeFamiliyTable and that only upon completion of that deletion process the snmpNgLpViewEntry is deleted from the snmpNgLpViewTable. Following these procedures there should be no collisions when multiple managers try to update the MIB views at an SNMPng entity in an agent role. " ::= { snmpNgLpMIBObjects 4 } snmpNgLpSubtreeFamilyEntry OBJECT-TYPE SYNTAX SnmpNgLpSubtreeFamilyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular family of view subtrees included in or excluded from a particular SNMPng context's MIB view. The MIB view must exist (i.e., be represented by a conceptual row in the snmpNgLpViewTable) 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 snmpNgLpSubtreeFamilyTable. The value of snmpNgLpViewIndex 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 { snmpNgLpViewIndex, IMPLIED snmpNgLpSubtreeFamilySubtree } ::= { snmpNgLpSubtreeFamilyTable 1 } Wijnen/Harrington Expires September 1977 [Page 21] Draft Local Processing Model (LPM) for SNMPng March 1997 SnmpNgLpSubtreeFamilyEntry ::= SEQUENCE { snmpNgLpSubtreeFamilySubtree OBJECT IDENTIFIER, snmpNgLpSubtreeFamilyMask OCTET STRING, snmpNgLpSubtreeFamilyType INTEGER, snmpNgLpSubtreeFamilyStorageType StorageType, snmpNgLpSubtreeFamilyStatus RowStatus } snmpNgLpSubtreeFamilySubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The MIB subtree which when combined with the corresponding instance of snmpNgLpSubtreeFamilyMask defines a family of view subtrees. " ::= { snmpNgLpSubtreeFamilyEntry 1 } snmpNgLpSubtreeFamilyMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "The bit mask which, in combination with the corresponding instance of snmpNgLpSubtreeFamilySubtree, defines a family of view subtrees. Each bit of this bit mask corresponds to a sub-identifier of snmpNgLpSubtreeFamilySubtree, 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 snmpNgLpSubtreeFamilySubtree, either: the i-th bit of snmpNgLpSubtreeFamilyMask is 0, or Wijnen/Harrington Expires September 1977 [Page 22] Draft Local Processing Model (LPM) for SNMPng March 1997 the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of snmpNgLpSubtreeFamilySubtree. If the value of this bit mask is M bits long and there are more than M sub-identifiers in the corresponding instance of snmpNgLpSubtreeFamilySubtree, 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 snmpNgLpSubtreeFamilySubtree. " DEFVAL { ''H } ::= { snmpNgLpSubtreeFamilyEntry 2 } snmpNgLpSubtreeFamilyType OBJECT-TYPE SYNTAX INTEGER { included(1), excluded(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The indication of whether the corresponding instances of snmpNgLpSubtreeFamilySubtree and snmpNgLpSubtreeFamilyMask define a family of view subtrees which is included in or excluded from the MIB view. " DEFVAL { included } ::= { snmpNgLpSubtreeFamilyEntry 3 } snmpNgLpSubtreeFamilyStorageType 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 } ::= { snmpNgLpSubtreeFamilyEntry 4 } Wijnen/Harrington Expires September 1977 [Page 23] Draft Local Processing Model (LPM) for SNMPng March 1997 snmpNgLpSubtreeFamilyStatus 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 snmpNgLpSubtreeFamilyStatus 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. " ::= { snmpNgLpSubtreeFamilyEntry 4 } -- Information about TRAP destinations ******************************* snmpNgLpTrapDestTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpNgLpTrapDestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The transport addresses to which notifications (traps) are to be sent on behalf of specific SNMPng groups. " ::= { snmpNgLpMIBObjects 5 } snmpNgLpTrapDestEntry OBJECT-TYPE SYNTAX SnmpNgLpTrapDestEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A transport address to which notifications (traps) are to be sent on behalf of a specific SNMPng group " INDEX { snmpNgLpTrapDestTDomain, IMPLIED snmpNgLpTrapDestTAddress } ::= { snmpNgLpTrapDestTable 1 } SnmpNgLpTrapDestEntry ::= SEQUENCE { snmpNgLpTrapDestTDomain TDomain, snmpNgLpTrapDestTAddress TAddress, snmpNgLpTrapDestQos SnmpNgQos, Wijnen/Harrington Expires September 1977 [Page 24] Draft Local Processing Model (LPM) for SNMPng March 1997 snmpNgLpTrapDestGroupName SnmpGroupName, snmpNgLpTrapDestSecModel SnmpNgSecurityModel, snmpNgLpTrapDestStorageType StorageType, snmpNgLpTrapDestStatus RowStatus } snmpNgLpTrapDestTDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the kind of transport service for this transport address. " DEFAULT { snmpUDPDomain } ::= { snmpNgLpTrapDestAddressEntry 1 } snmpNgLpTrapDestTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The transport service address. The address is formatted according to the corresponding value of snmpNgLpTrapDestTDomain. For example, for the transport domain corresponding to the snmpUDPDomain, transportAddress is formatted as a 4-octet IP Address concatenated with a 2-octet UDP port number. See [RFC1906] for more information on transport domains and how their corresponding addresses are formatted. " ::= { snmpNgLpTrapDestEntry 2 } snmpNgLpTrapDestQos OBJECT-TYPE SYNTAX SnmpNgQos MAX-ACCESS read-create STATUS current DESCRIPTION "The Qos to use when sending a notification (trap) to this destination. " DEFVAL { 2 } -- auth ::= { snmpNgLpTrapDestEntry 4 } snmpNgLpTrapDestGroupName OBJECT-TYPE SYNTAX SnmpNgGroupName MAX-ACCESS read-create STATUS current Wijnen/Harrington Expires September 1977 [Page 25] Draft Local Processing Model (LPM) for SNMPng March 1997 DESCRIPTION "The group name to use when applying access control to the management information contained in the notification (trap) to be sent. " ::= { snmpNgLpTrapDestEntry 5 } snmpNgLpTrapDestSecModel OBJECT-TYPE SYNTAX SnmpNgSecurityModel MAX-ACCESS read-create STATUS current DESCRIPTION "The Security Model to use when applying security measures to the SNMP message before sending it to this destination. " ::= { snmpNgLpTrapDestEntry 6 } snmpNgLpTrapDestStorageType 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 } ::= { snmpNgLpTrapDestEntry 7 } snmpNgLpTrapDestStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row." ::= { snmpNgLpTrapDestEntry 8 } -- Conformance information ******************************************* snmpNgLpMIBCompliances OBJECT IDENTIFIER ::= { snmpNgLpMIBConformance 1 } snmpNgLpMIBGroups OBJECT IDENTIFIER ::= { snmpNgLpMIBConformance 2 } -- Compliance statements ********************************************* snmpNgLpMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPng entities which implement the SNMPng LP-M remote configuration MIB. " MODULE -- this module MANDATORY-GROUPS { snmpNgLpBasicGroup } Wijnen/Harrington Expires September 1977 [Page 26] Draft Local Processing Model (LPM) for SNMPng March 1997 OBJECT snmpNgLpViewStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpNgLpViewStatus MIN-ACCESS read-only DESCRIPTION "Create access to the snmpNgLpViewTable is not required. " OBJECT snmpNgLpSubtreeFamilyMask WRITE-SYNTAX OCTET STRING (SIZE (0)) MIN-ACCESS read-only DESCRIPTION "Support for configuration via SNMPng of subtree families defined using wild-cards is not required. " OBJECT snmpNgLpSubtreeFamilyStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpNgLpSubtreeFamilyStatus MIN-ACCESS read-only DESCRIPTION "Create access to the snmpNgLpSubtreeFamilyTable is not required. " ::= { snmpNgLpMIBCompliances 1 } -- Units of conformance ********************************************** snmpNgLpBasicGroup OBJECT-GROUP OBJECTS { snmpNgLpContextStatus, snmpNgLpAcPrivileges, snmpNgLpAcReadViewIndex, snmpNgLpAcWriteViewIndex, snmpNgLpAcStorageType, snmpNgLpAcStatus, snmpNgLpViewStorageType, snmpNgLpViewStatus, snmpNgLpSubtreeFamilyMask, snmpNgLpSubtreeFamilyType, snmpNgLpSubtreeFamilyStorageType, -- length 32 !! snmpNgLpSubtreeFamilyStatus, snmpNgLpTrapDestQos, snmpNgLpTrapDestGroupName, snmpNgLpTrapDestSecModel, snmpNgLpTrapDestStorageType, snmpNgLpTrapDestStatus } Wijnen/Harrington Expires September 1977 [Page 27] Draft Local Processing Model (LPM) for SNMPng March 1997 STATUS current DESCRIPTION "A collection of objects providing for remote configuration of an SNMPng entity which implements the SNMPng Local Processing Model (LP-M). " ::= { snmpNgLpMIBGroups 1 } END Wijnen/Harrington Expires September 1977 [Page 28] Draft Local Processing Model (LPM) for SNMPng March 1997 5. Security Considerations 5.1 Recommended Practices This document is part of the SNMPng Architectural Model. The Local Processing Model (LP-M) 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 Implenetation (LP-I) 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 SNMPng Securty Framework Model (SF-M). - Qos used for the transmission of a SNMP message. When the LP-I is called for processing a Scoped-PDU, it is assumed that the Message Processing and Control Implementation (MPC-I) has ensured the authentication and privacy aspects as specified by the Quality of service (Qos) 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 snmpNgLpAcTable. By mapping a security entity into a group, a SF-M for SNMPng can add/delete entities to a group. 5.3 Conformance Conformance rules are described in the Architectural Model for SNMPng. Wijnen/Harrington Expires September 1977 [Page 29] Draft Local Processing Model (LPM) for SNMPng March 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-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 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/Harrington Expires September 1977 [Page 30] Draft Local Processing Model (LPM) for SNMPng March 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-snmpv3-arch-00.txt, March 1997. [SNMPng-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D., "Local Processing Model for the Next Generation Simple Network Management Protocol (SNMPng)", draft-ietf-snmpv3-lpm-00.txt, March 1997. [SNMPng-USEC] To be written The SNMPng Working Group, Editors...Names, "The User-Based Security Model for the Next Generation Simple Network Managememt Protocol (SNMPng)", draft-ietf-snmpv3-usec-00.txt, April 1997. Wijnen/Harrington Expires September 1977 [Page 31] Draft Local Processing Model (LPM) for SNMPng March 1997 APPENDIX A - Installation Editor's notes: portions of the following still need to be moved to the appropriate documents. I am just listing them here so that we have one place where we can see what is needed. End Editor's notes. A.1. Agent Installation Parameters During installation, an SNMPng entity acting in an agent role is configured with several parameters. These include: (1) a security posture (todo in SNMPng-MPC) 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) one or more transport service addresses (todo in SNMPng-MPC) These parameters may be specified explicitly, or they may be specified implicitly as the same set of network-layer addresses configured for other uses by the device together with the well- known transport-layer "port" information for the appropriate transport domain [RFC1906]. The agent listens on each of these transport service addresses for messages. (3) one or more secrets (todo in SNMPng-USEC) These are the authentication/privacy secrets for the first user to be configured. One way to accomplish this is to have the installer enter a "password" for each required secret. The password is then algorithmically converted into the required secret by: - forming a string of length 1,048,576 octets by repeating the value of the password as often as necessary, truncating accordingly, and using the resulting string as the input to the MD5 algorithm. The resulting digest, termed "digest1", is used in the next step. - a second string of length 44 octets is formed by concatenating digest1, the SNMPng engine's snmpNgEngineID value, and digest1. This string is used as input to the MD5 algorithm. Wijnen/Harrington Expires September 1977 [Page 32] Draft Local Processing Model (LPM) for SNMPng March 1997 The resulting digest is the required secret (see Appendix A.2). With these configured parameters, the SNMPng entity instantiates the following snmpNgUsecUserEntry, no privacy support privacy support ------------------ --------------- snmpNgUsecEngineID localEngineID localEngineID snmpNgUsecUserName "public" "public" snmpNgUsecGroupName "public" "public" snmpNgUsecAuthProto snmpMD5Protocol snmpMD5Protocol snmpNgUsecPrivProto none snmpDESProtocol snmpNgUserSecurityCookie "" "" (4) The SNMPng LP-M the SNMPng entity in an agent role must instantiate the following views and access rights. This configuration information should be readOnly (persistent). - One context with its as the empty-string "". This represents the default context. - 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] "snmpNgStats" [SNMPng-ARCH] "snmpNgUsecStats" [SNMPng-USEC] - For the "semi-secure" posture: the MIB view is the union of these subtrees: "snmp" [RFC1907] "snmpNgStats" [SNMPng-ARCH] "snmpNgUsecStats" [SNMPng-USEC] "system" [RFC1902] - For the "minimum-secure" posture: the MIB view is the following subtree. "internet" [RFC1902] Wijnen/Harrington Expires September 1977 [Page 33] Draft Local Processing Model (LPM) for SNMPng March 1997 - Access rights to allow: - read-only access for Qos "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 Qos "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 Qos "auth" on behalf of security entities that belong to the group "public" to the MIB view in the context with contextName "". Wijnen/Harrington Expires September 1977 [Page 34] Draft Local Processing Model (LPM) for SNMPng March 1997 A.2. Password to Key Algorithm Editor's Notes: The following goes into SNMPng-USEC doc. End Editor's notes. The following code fragment demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key. The calls to MD5 are as documented in RFC1321 [RFC1321] void password_to_key( u_char *password, /* IN */ u_int passwordlen, /* IN */ u_char *agentID, /* IN - ptr to 12 octet long snmpEngineID */ u_char *key) /* OUT - caller's pointer to 16-byte buffer */ { MD5_CTX MD; u_char *cp, password_buf[64]; u_long password_index = 0; u_long count = 0, i; MD5Init (&MD); /* initialize MD5 */ /**********************************************/ /* Use while loop until we've done 1 Megabyte */ /**********************************************/ while (count < 1048576) { cp = password_buf; for (i = 0; i < 64; i++) { /*************************************************/ /* Take the next byte of the password, wrapping */ /* to the beginning of the password as necessary.*/ /*************************************************/ *cp++ = password[password_index++ % passwordlen]; } MDupdate (&MD, password_buf, 64); count += 64; } MD5Final (key, &MD); /* tell MD5 we're done */ /*****************************************************/ /* Now localize the key with the agentID and pass */ /* through MD5 to produce final key */ /*****************************************************/ memcpy(password_buf, key, 16); memcpy(password_buf+16, agentID, 12); memcpy(password_buf+28, key, 16); MD5Init(&MD); MDupdate(&MD, password_buf, 44); Wijnen/Harrington Expires September 1977 [Page 35] Draft Local Processing Model (LPM) for SNMPng March 1997 MD5Final(key, &MD); return; } Wijnen/Harrington Expires September 1977 [Page 36] Draft Local Processing Model (LPM) for SNMPng March 1997 Table of Contents 0. Change Log 2 1. Introduction 3 1.1 Terminology 3 1.2 Local Processing 3 1.3 Local Configuration Datastore 4 2. Elements of the Model 5 2.1 SNMPng Group 5 2.2 SNMPng Quality of Service (Qos) 5 2.3 Contexts 5 2.4 SNMPng Scoped-PDU 6 2.5 Access Policy 7 2.6. Error Reporting 7 3. Elements of Procedure 8 3.1 Processing a Received Scoped-PDU 8 3.2 Generating a Notification 10 4. Definitions 12 5. Security Considerations 29 5.1 Recommended Practices 29 5.2 Defining Groups 29 5.3 Conformance 29 6. Editor's Addresses 30 7. Acknowledgements 30 8. References 31 A.1. Agent Installation Parameters 32 A.2. Password to Key Algorithm 35 Wijnen/Harrington Expires September 1977 [Page 37]