draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 Overview of SNMPv2 Simplified Security Conventions Mar 24, 1994 Steven Waldbusser Carnegie Mellon University waldbusser@cmu.edu 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 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 a "work in progress". Waldbusser Expires Sep 24, 1994 [Page 1] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 1. Introduction This document set describes conventions that simplify the administration and usage of SNMPv2 Security. These conventions are for use by cooperating and consenting SNMPv2 entities and do not change or restrict any other usage of SNMPv2 security. This document provides an overview of these conventions, and examples of usage at the user interface level. Waldbusser Expires Sep 24, 1994 [Page 2] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 2. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Waldbusser Expires Sep 24, 1994 [Page 3] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 3. Overview While SNMP security is an important issue on many networks today, current operational needs dictate that security be implemented and used in a way that doesn't harm the useability and reliability of network management applications. This memo defines conventions for the use of SNMP security that provide an easier to manage and easier to use system, without changing the protocol. The problem that network managers face with SNMP Security is the amount of information that must be configured consistently across multiple managers and agents before management communications may begin. This burdens the network manager whenever: o A new agent is installed Each time a new agent is installed, parties must be configured and installed on that agent, and the identical information must be installed on every management station that may need to communicate with that agent in the future. If a management station is left out, it is likely that the network manager will not find out that that station cannot communicate until a time of network (and human) stress. o A new management station is installed Each time a new management station is installed, it must be loaded with the authentication information for all agents it may ever need to communicate with. If this management station is a new product, the installer will probably need to translate the security configuration database to a new format before the installation may be completed, delaying the installation of this new product. If the configuration for a particular agent is left out, the manager will not be able to communicate with that agent on demand. In addition, every agent must be updated to include authentication information for that new management station. o The network manager needs to "firefight" from a new location When the network is experiencing stress and the network manager is firefighting, the network manager may need to run management applications from different locations on the network. This may be in an attempt to get closer to the problem or to "set up camp" in a portion of the network that actually works and allows the tools to Waldbusser Expires Sep 24, 1994 [Page 4] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 function. This activity is sometimes under extreme duress and time is always a factor. A setup time of more than a few minutes is simply unacceptable. In addition, the uncertainty associated with relying on a complex and untested configuration can reduce the network manager's effectiveness. o Every time a network address changes Every time a network address changes on a management station, all agents must be reconfigured with the new security information for that management station. Every time a network address changes on an agent, all management stations must be similarly reconfigured with new security information. Some of these problems may be reduced with automatic configuration programs, standard file formats and other schemes. However, these schemes don't purport to solve all of these problems, and are neither widely available, implemented, nor even proven tractable. This document set describes conventions that simplify the administration and usage of SNMPv2 Security. These conventions are for use by cooperating and consenting SNMPv2 entities and do not change or restrict any other usage of SNMPv2 security. These conventions have the following advantages: o No security administration servers are required to maintain clocks or to administer parties and passwords. o Many fewer parties required in the system, and even fewer "configuration items" o Security configuration may be performed quickly, on demand by a human o Less NVRAM storage requirements o With a clock-calendar chip, periodic writes to NVRAM are not required. o No clock leapfrog problems 4. General Strategy The Party MIB configuration for every given situation (perhaps every particular combination of agent, management platform, and application) either has to be memorized or be pre-configured on every system that might need to communicate using SNMPv2 security. As a complete pre- configuration has been difficult to implement and deploy, this memo describes a strategy that provides a simplified configuration that can Waldbusser Expires Sep 24, 1994 [Page 5] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 be algorithmically derived, except for a minimal amount of information that is input by a human. This human-entered information is in a format that may be easily memorized and produced on demand, and is in a userid, password form that network administrators are quite familiar with. This specification introduces the concept of a userID to SNMPv2 Security. A userID names a set of security information that is used to provide authentication and privacy functions for a user. Each userID is represented by the configuration of two or four pairs of parties in the SNMP Party MIB. In the absence of these conventions, quite a few parties and other elements of security information would need to be configured. From the user perspective, this userid and a secret are the only things that need to be remembered. The next part of the strategy is that the Party MIB configuration for a user is authoritatively defined on each agent which is being secured by the protocol. This same configuration is used by all management stations that may need to communicate with that agent using a particular userID. For example, Joe Administrator will use the same security information to reboot Router1 whether he is on NMS1 or NMS2. This will typically be different than Jane Administrator's configuration for Router1. In fact, each element of the party table configuration will be named by the network address of the agent and the userid of the user. This enables the information (such as the secret) to be different for each agent or to be shared across agents. This allows a different secret to be required for each system a user manages if security needs dictate, or for a user to use the same key on many systems. When using these conventions, a user will likely use the same configuration from multiple management stations. In order to ensure that no harmful interactions occur, additional rules are provided that detail how the NMS will interact with the agent. In particular, usage of clock values is constrained so that harmful interactions such as clock leapfrog will not occur. The next step in the strategy is to provide a mechanism in which the party table configuration for a user may be algorithmically derived with a minimum of information provided by a human. The conventions specify that each userID will result in four parties being created on the agent. On both the manager and the agent, the human needs to specify a userid and a password, while the agent also requires access control information to be specified. Waldbusser Expires Sep 24, 1994 [Page 6] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 In SNMPv2 Security, Parties and Contexts are named by OBJECT IDENTIFIERs. Unfortunately, it is effectively impossible for humans to remember these strings and to input them on demand. This specification provides conventions on how those OBJECT IDENTIFIERs may be derived from the address of the agent and other simple pieces of information. In SNMPv2 Security, authentication keys are 16 random binary bytes. These too are effectively impossible for a human to remember. This specification provides a secure way that the key may be derived from an ASCII password input by a human. This can be a single word or a phrase of several words. After participating systems gather a minimal amount of information from a human and create the required party MIB configuration, communications may begin with no further configuration necessary. These conventions therefore allow the security configuration to be created on demand and obviates the need for pre-configuration. These conventions allow implementation strategies that will achieve additional benefits. For example, an implementation may store just the userid and password in NVRAM and translate them to Party MIB elements upon initialization, saving NVRAM space. Implementions may choose to delay the translation even further by performing a temporary translation only when a particular userID is used. Administrators may choose to use the same userid and password across several machines, and management stations may be configured to make it quite easy to access these similarly configured machines. 5. Examples of the public noAuth/noPriv configuration When implemented, this configuration will work "out of the box" without any configuration by the end user for either the management station or the agent. It is mandatory the the agent support this configuration for read-only access to the party clocks (at least). Usage of this will be much like SNMPv1's use of the "public" community string. This is arguably simpler than SNMPv1, because no parameter needs to be given at all. Waldbusser Expires Sep 24, 1994 [Page 7] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 6. Examples of MD5 authentication configuration 6.1. Agent Initialization Examples The agent's user interface might take many forms, depending on the extent of configurability that the agent allows. Some examples follow. 6.1.1. Minimal Agent A user dialog when configuring a minimal agent might look like: ======================================== ACME Bridge SNMPv2 Initialization Please enter the password for the "admin" userid: ...... Passwords must be at least 8 characters. Please try again. Please enter the password for the "admin" userid: ...................... ======================================== In this example, the agent only provides a single userID named "admin", and asks the installer/configurer for a password for this userID. Waldbusser Expires Sep 24, 1994 [Page 8] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 6.1.2. Normal Agent A user dialog when configuring a normal agent might look like: ======================================== ACME Router SNMPv2 Initialization Please enter a userid: joe Please enter the password for joe: ...................... Please enter the view for joe. Select one of the following: 1) system and IP host configuration 2) IP routing configuration, system, and IP host configuration 3) Everything, including SNMP Security Enter your selection: 2 Do you want to configure any more users? [y/n]: n ======================================== In this example, the agent allows a number of users to be configured and for each to have different permissions on the agent. Waldbusser Expires Sep 24, 1994 [Page 9] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 6.1.3. Extended Agent A user dialog when configuring an agent with extensive SNMP Security support might look like: ======================================== ACME Chassis SNMPv2 Initialization Please enter a userid: joe Please enter the password for joe: ...................... Select a context, or n for new: SubSystem Time View 1) main current default 2) repeater1 current default Enter your selection: n What subsystem should this user have access to: 1) repeater1 2) repeater2 Enter your selection: 2 Please enter a group to provide access to. Select one of the following: 1) system 2) repeater 3) ACME private MIB 4) RMON MIB 5) Done, no more groups Enter your selection: 1 Please enter a group to provide access to. Select one of the following: 1) system 2) repeater 3) ACME private MIB 4) RMON MIB 5) Done, no more groups Enter your selection: 3 Please enter a group to provide access to. Select one of the following: 1) system 2) repeater 3) ACME private MIB 4) RMON MIB 5) Done, no more groups Enter your selection: 5 What should this view be called?: admin Running configuration, or default? [Running/Default]: Running Read-Write access? [y/n]: y Added context #3. Select a context, or n for new: SubSystem Time View Waldbusser Expires Sep 24, 1994 [Page 10] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 1) main current default 2) repeater1 current default 3) repeater2 current admin 0) Done, no more contexts Enter your selection: 1 Added context #1. Select a context, or n for new: SubSystem Time View 1) main current default 2) repeater1 current default 3) repeater2 current admin 0) Done, no more contexts Enter your selection: 0 Done with joe. Do you want to configure any more users? [y/n]: n ======================================== In this example, the agent allows a number of users to be configured and for each to have an access control list to be built up, and for different subsystems to be controlled. 6.2. Manager Initialization While the agent configurations can be quite simple, the manager needs even less information to become fully configured. In the simplest case, only a userID and a password are required. In this example we will show the use of a command line tool, as it is the application that is least likely to be used with a pre-configured security database, especially when firefighting. The following example could be followed without any prior initialization (e.g., if the snmpset program had just been pulled off of a CDROM onto a new system). ======================================== % snmpset acme-router joe sysLocation.0 "UCC 130" Password: ...................... sysLocation.0 = UCC 130 [Done]. % snmpset acme-chassis joe sysLocation.0 -e repeater1 "UCC 130" Password: ...................... sysLocation.0 = UCC 130 [Done]. % ======================================== A cache of userid-key mappings may be used to avoid the frequent typing of passwords, and to cut down on the time involved in the password to key algorithm. Obviously this database must be kept private and must Waldbusser Expires Sep 24, 1994 [Page 11] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 only be used by authorized users. Waldbusser Expires Sep 24, 1994 [Page 12] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 7. Acknowledgements The author wishes to thank Jeff Case, Jim Galvin, Jeff Johnson, Peter Houck, Keith McCloghrie, John Myers, and Brian O'Keefe for their helpful comments on the ideas in this document. Waldbusser Expires Sep 24, 1994 [Page 13] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 8. References [1] Galvin, J., and McCloghrie, K., "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April, 1993 [2] Galvin, J., and McCloghrie, K., "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN Systems, April, 1993 [3] McCloghrie, K., and Galvin, J., "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN Systems, Trusted Information Systems, April, 1993 Waldbusser Expires Sep 24, 1994 [Page 14] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 9. Author's Address Steven Waldbusser Carnegie Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 US Phone: +1 412 268 6628 Email: waldbusser@cmu.edu Waldbusser Expires Sep 24, 1994 [Page 15] draft Overview of SNMPv2 Simplified Security Conventions~Mar 24, 1994 Table of Contents 1 Introduction .................................................... 2 2 The SNMPv2 Network Management Framework ......................... 3 3 Overview ........................................................ 4 4 General Strategy ................................................ 5 5 Examples of the public noAuth/noPriv configuration .............. 7 6 Examples of MD5 authentication configuration .................... 8 6.1 Agent Initialization Examples ................................. 8 6.1.1 Minimal Agent ............................................... 8 6.1.2 Normal Agent ................................................ 9 6.1.3 Extended Agent .............................................. 10 6.2 Manager Initialization ........................................ 11 7 Acknowledgements ................................................ 13 8 References ...................................................... 14 9 Author's Address ................................................ 15 Waldbusser Expires Sep 24, 1994 [Page 16]