Minutes - IETF #40 Washington, D.C. ------------------------------------ WG: DISMAN Area: OPS Meetings: 10dec97 1930-2200 12dec97 0900-1130 WG Chair: Randy Presuhn Minutes: Andy Bierman Summary ------- The DISMAN WG met at this meeting to advance the documents in progress. Most of the meeting time was used addressing difficult security issues. Many aspects of script and expression configuration and operation within a secure SNMPv3/VACM environment were discussed, and a great deal of progress was made in this area. Agenda ------ 1. Administrative issues 1.1 Review of agenda & adjustments 1.2 Mailing List Information 1.3 Charter Updates - yes the revised charter has been submitted to our area directors. 1.4 Allocation of time for discussions 2. Technical Presentations none currently scheduled, please let the chair know in advance so time can be budgeted 3. General Technical Discussion 3.1 Impact of SNMPv3 work 3.1.1 terminology 3.1.2 application types 3.1.3 access control implications 3.2 Framework issues 3.2.1 Do we still need it? 3.2.2 Alignment with SNMPv3 work 3.3 Target MIB 3.3.1 Editor's overview of changes 3.3.2 Alignment with SNMPv3 work 3.4 Script MIB issues 3.4.1 Editor's overview of changes 3.4.2 Alignment with SNMPv3 work 3.4.2.1 Naming 3.4.2.2 Access Control 3.5 Expression evaluation MIB issues 3.5.1 implementation experience 3.5.2 impact of SNMPv3 support 3.6 Notification MIB 3.7 Common issues 3.7.1 integration with other mibs 3.7.2 conformance issues 3.7.3 representing ownership 3.7.4 security considerations 3.7.5 implementability 3.7.6 deployability 3.7.7 internationalization 4. Future work 5. Closing 5.1 Review of action items 5.2 Planning for possible interim meeting 5.3 Discussion of next meeting Reading Material ---------------- ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-event-mib-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-express-mib-02.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-framework-00.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-mgt-target-mib-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-notify-mib-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-disman-script-mib-01.txt 1) Technical Presentations -------------------------- Several of the document authors gave presentations on specific issues relating to the DISMAN work. 1.1) David Levi -- Trap Forwarding Application The SNMPv3 framework does not allow a trap receiver application to receive all information related to a given trap PDU, particularly the original source address, if that trap was received via at least one trap forwarder. The 'ContextSNMPEngineId' (where info came from), doesn't change from hop to hop, but 'AuthSNMPEngineId' does change from hop to hop. It is not possible with the Proxy MIB to determine the original source address. A proposal was made for proxied traps, to add a varbind in the trap identifying the original source address. The WG decided to defer the issue to the SNMPv3 working group for resolution. 1.2) Bob Stewart -- Expression MIB Implementation Experience Implementing the Expression MIB is non-trivial. Many people were involved in the agent implementation effort, which took approximately 18 person-months to complete. This implementation experience resulted in many clarifications, reflected in the latest draft. Status of the new draft: * A new object has been added to indicate if an expression object is identified with a partial OID (and should be 'wildcard-expanded'), or if the OID is complete (and should not be 'wildcard-expanded'). * Access control issues need to be resolved. New comments in the MIB are needed to clarify access control. * A 'changedElement' expression operator was added. This is needed to flag a changed object value, which can't be done with arithmetic operators for all object types (e.g., OID). Operation of integer deltas does not change. * The Editor needs to finish the Event MIB to fully support the Expression MIB. * A change to the Event MIB was made to use Notifications to log errors. * Event MIB error handling needs some clarifications * Expression MIB needs an overview, and more front-end prose describing NMS constraints and usage guidelines. The WG discussed the merits of these changes and the Expression MIB in general. The use of notifications to flag expression errors is controversial. It was noted that work on universal logging is being done in two other working groups. The new draft will be discussed further on the mailing list. 1.3) Juergen Schoenwaelder -- Security Issues & Terms Security profiles control configuration and execution access to scripts and expressions, and a script needs to be restricted to specific services on the runtime system. The security profile of the script installer (script owner) is used to specify who can run the script and which 'execution security profiles' may be used (by which users) to execute the script. The installer profile may be different than the execution profile. The VACM MIB is used to control configuration and execution access. The WG agreed that a description of how to use VACM to secure a DISMAN system should be added to the document. A unix-like "SETUID" capability is needed to allow a third party to start a script, running under security profile of the script owner, not the script invoker. During the course of the meetings, a great deal of discussion focused on the security details of many such configuration and execution scenarios. The DISMAN MIB(s) should not assume that a particular security model is used, which means the security profile information must be available in the MIB(s). The WG should establish guidelines for configuring user names, and a 'mapping table' indicating context name to local user/group name on the execution target. Mappings for 'owner-to-local-user' and 'invoker-to-local-user' are needed. 1.4) Steve Waldbusser -- Framework Terminology Issues A distributed system can be modeled as three logical components: +-----------+ +----------------+ +------------------+ | |+ disman | |+ target | |+ | Higher || user | Distributed || user | Target Agent || | Layer || ------> | Manager || ------> | or Network Host || | Mgmt || | [users] || | [users] || | App || | [scripts/exprs]|| | [scripts/exprs] || | || ++---------------+| | [managed system] || ++----------+| +----------------+ ++-----------------+| +-----------+ +------------------+ Each of these logical components can be physically located on the same machine or different machines. The "disman user" and "target user" are identified by more than a user ID: - disman user: SNMP Security Model, Security Name & Key; allowed to install and manage disman functionality on specific distributed managers - target user: SNMP Security Model, Security Name & Key; allowed to invoke specific DISMAN functions on specific targets Tokens are used to describe all necessary information needed to perform particular operations on behalf of the disman user. SNMPv3 makes it clear what these objects are; - securityModel - securityName; - set of targets; - set of access rights for those targets There may be a set of tokens per target user of each script or expression. Invocation properties of a script or expression must be attached to the invocation button, not the configuration of the control rows. A script installer may wish to limit the set of tokens that a particular script invoker may use (for that script) Token subsets are constant subsets, and to create a different set of credentials, new tokens must be created. To utilize a DISMAN system, first a disman user configures a Distributed Manager by installing some scripts, some user names, some security tokens, and then associating scripts to tokens, based on the functional requirements of the script, and the profile of each target user. Remaining Issues: a) After a script is configured, a Script Invoker can start the script running. Is the 'Script Invocation Identity' the ID of the owner or the invoker? b) The Expression MIB has notion of invoker and owner as well. The WG needs to develop one VACM-based DISMAN security architecture. What changes to the various MIBs are needed? c) There may be several tokens available per user per script. How do you tell which tokens to use? Care should be taken to avoid an explosion of configuration rows needed on each Distributed Manager (e.g., one token per target-user, per target, per target-context, per target-MIB-view). d) What if User A installs a script; user B wants to reuse the script with his/her own tokens? Should this be supported? e) How do you tell which tokens are used, if different values of contextName are needed to access a given MIB object on a target system? f) How should the combinations of credentials be supported? - owner - subset of owner - invoker - union of owner and invoker 1.5) David Levi & Juergen Schoenwaelder -- Session Control The Script MIB needs to support some forms of script scheduling: one-shot -- invoked once when 'invoke button' is pressed periodically -- like unix 'cron' command time-of-day -- like unix 'at' command A new table to support the time-based scheduling will be added to the Script MIB. The WG decided not to support script invocation based on reception of an SNMP notification. Instead, a script may listen for notifications in a platform-specific, proprietary way. It is likely that only one script will be able to listen for notifications on some platforms. This issue may be addressed in a future version of the Framework document. 2) Issues List Follow-up ------------------------ After all presentations, the WG Chair led a discussion of issues related to all documents in progress. The topics were ordered, based on complexity: - Quick List (2.1 .. 2.10) - Tough List (2.11 .. 2.17) 2.1) Framework draft The Framework draft has expired and needs to be updated. Action Item (Steve Waldbusser): Align terms in FW draft with the new terminology tentatively accepted by the WG. Add detailed example of configuring VACM and the script MIB to maintain security and usefulness. 2.2) UTF-8 The WG should examine all strings for proper application of UTF-8 based strings. It should be used for true internationalization, not localization, since many options make communication more difficult, not easier. 2.3) Event MIB Terminology The terminology in the Event MIB (and possibly the Expression MIB) needs to be aligned with the (new) terminology in the Framework draft. 2.4) Script Return Status Codes The script return codes are defined with inline syntax, as opposed to the use of a textual convention to identify the status codes. This should be declared as a TC only if it is appropriate to ever export them for use in another MIB module. Since this is likely to occur in the long-term, due to the augmentation of the Script MIB, it may be better to move the return code definitions to a TC definition now. 2.5) Script Download Compliance The Script MIB compliance statements need to be refined to allow: - 'push' downloading of scripts (via SNMP) is optional - 'pull' downloading of scripts (via URL) is optional to support a special class of disman agent with only pre-defined read-only scripts 2.6) Suspend/Resume Commands Should the Script MIB support suspend/resume 'script states', and therefore allow (or require) a script to support these commands? This issue was hotly debated, and WG consensus for this feature has not yet been established. It was noted that these commands require 'signals' between the DISMAN platform and a running instance of a script, and that the suspend and resume signals are just two on a list of possible signals that a user may wish to send to a running script instance. A DISMAN implementation must send such signals to scripts in a platform-specific way. If a script to chooses to suspend or optionally ignore the signal, how does an NMS know the suspend command worked or not? The response to the SetPDU will probably indicate success, even if the script instance actually ignored the signal. 2.7) SmCodeTable Line Numbers Should the smCodeTable allow non-contiguous line numbers during a sequence of smCodeTable SetPDU, i.e., script line insertions. Resolution -- relax the rule requiring line numbers to be contiguous, but do not allow the insertion of lines, i.e. smCodeTable insertions must be in ascending order in successive SetPDUs. 2.8) Process IDs (PIDs) A unique invocation identifier is needed for each instance of all scripts, regardless of running state. The DISMAN platform should provide an automatic PID generator, i.e., the NMS must not be involved in the PID generation, but the PID value should be available via the Script MIB. The agent should allow smLaunchStart to be set to zero, which indicated that the system assigns the PID. [ed. - open issue: does this mean the agent has to support NMS PID generation, or is it optional, or completely disallowed?] 2.9) smLanguageIndex Should the smLanguageIndex be a table column instead of an INDEX component, and allowed to be zero? [ed. - It's not clear which tables are affected by this change; could be the smScriptEntry, smCodeEntry, smExecEntry, and smRunEntry. The WG agreed that the script language should be indicated in a column rather than an INDEX. If the column value equals zero, then a hardcoded script language is implied and there is no need to specify it. This feature was debated, since the default language must be specified in the smLanguageTable anyway. Allowing the value zero means that another MIB object will be required to indicate the mapping between the default (0), and some language in the smLanguageTable. It's better to conserve MIB objects and make the language identifier reference a real smLanguageTable entry. This issue will be discussed further on the mailing list. 2.10) Deferment of NV-Storage A feature will be added to the Script MIB, to allow an agent implementation to defer NV storage of a script until all the code lines are downloaded. This will be dome by adding an editing state to the scriptStatus. This feature also allows the agent to determine the actual NV-storage size, instead of wasting resources writing partial scripts to NV-storage. 2.11) Script Results Can the valueTable in the Expression MIB be used to make script results visible? This MIB uses a discriminated union of MIB object results instead of a string result. This issue will be discussed further on the mailing list. 2.12) Logging MIB Status Should these features be developed or dropped from the first release of DISMAN documents: - error logging feature - notification log This issue will be discussed further on the mailing list. [ed. - end of day 1; start day 2] 2.14) Naming Scope A suggestion was made to use naming scope to isolate each user of the scripting capability, instead of providing a multitude of launchpad buttons for each script. There were objections to this approach, based on available tools and experience (e.g., RepeaterID). Resolution: The namingScope (contextName) will not be used to isolate each user's view of the Script MIB or Expression MIB. 2.15 Script MIB Discussion The WG discussed the MIB structures required to implement the desired script/expression VACM-based access control/security features. The following is a summary of the MIB components: * table of scripts - INDEX script-id, scriptOwner - script.*.owner -> r/w (for group of owner) * launch pads - many buttons to the same script allowed - launch.*.owner -> r/w (for group of owner) - launch.start-button.owner -> r/w (for some others) [optional] * smRunTable - one per running script - run.*.owner -> r/w for that owner - run.*.owner -> r/w for others (optional) (also applies to tokens : token.*.owner) * tokens - associated with the launch pad, not the script - INDEX - owner, launchpadId, tokenInstanceId - tokens used on individual targets - script to launchpad mapping must be restricted to the same group - public-launchpad: issue is restricting the tokens used with the script instance - combining privileges needed to save rows? combining privileges may produce security holes & unexpected privileges; already behind schedule 9 months, perhaps add this in a later release. * mapping: owner --> 'local tokens' - needed to execute local operations - mapping: owner --> local tokens SecurityLevel SecurityName For expressions, this recorded at row-create-time, i.e., whoever activates the row that evaluates the expression. * tokenTable - MIB objects: INDEX [tokenOwner, tokenIndex]; tokenOwner string tokenIndex int tokenSecurityName string tokenSecurityLevel int tokenSecurityModel int tokenSecurityKey string - used to limit the list of target systems - why do we need this? don't have a way to delegate write access to the SNMPv3 targetTable (targetTable == an access right on a given system). - can the SNMPv3 targetTable be used instead of a DISMAN token table? V3 needed for trap destinations; Issues raised: - Does the requirements for proxy cover the requirements of DISMAN? - Does admin for proxy cover the admin requirements of DISMAN? - Resolution: use the SNMPv3 target tables; use the tags feature to subset the target list. 2.16) Expression MIB To support the VACM-based DISMAN security features, the expression owner needs to be part of the expression index. The details of this change were not explored, but this discussion will continue on the mailing list. 2.17) Document Complexity There was concern expressed about the complexity of the DISMAN technology, and conveying that complexity to users in the documents. More examples are needed, starting with simple applications and then introducing more complex applications. The Expression MIB needs examples written which show how the main features are used, with both simple and complex expressions. 3) Conclusions 3.1) Action Items * The deferred issues (mentioned throughout the minutes) will be discussed on the mailing list. * The DISMAN drafts will be updated to reflect the changes agreed upon at this meeting. * The (currently expired) Framework document will be resubmitted. 3.2) Interim Meeting A possible interim meeting was discussed again. Location was not an issue, but the proposed locations are all in the USA: - San Jose, CA - Chicago, IL - Houston, TX There is not strong interest in an interim meeting at this time. Many principal members of the working group met twice before the IETF meeting to discuss the documents in detail. This interim meeting approach may be repeated again before the next IETF meeting in Los Angeles, CA.