Internet DRAFT - draft-waldbusser-ssecov

draft-waldbusser-ssecov



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:05:16 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 24 Mar 1994 23:00:00 GMT
ETag: "3ddbba-5123-2d921b70"
Accept-Ranges: bytes
Content-Length: 20771
Connection: close
Content-Type: text/plain





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

                    
                    <draft-waldbusser-ssecov-00.txt>


                          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]