2.4.12 SNMP Version 3 (snmpv3)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 18-Oct-99


Russ Mundy <mundy@tislabs.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:snmpv3@lists.tislabs.com
To Subscribe: snmpv3-request@lists.tislabs.com
Archive: ftp://ftp.tislabs.com/pub/ietf/snmpv3

Description of Working Group:

The SNMPv3 Working Group is chartered to prepare recommendations for the next generation of SNMP. The goal of the Working Group is to produce the necessary set of documents that will provide a single standard for the next generation of core SNMP functions.

During the past several years, there have been a number of activities aimed at incorporating security and other improvements to SNMP. Unfortunately, strongly held differences on how to incorporate these improvements into SNMP prevented the SNMPV2 Working Group from coming to closure on a single approach. As a result, two different approaches (commonly called V2u and V2*) have emerged.

The Security and Administrative Framework Evolution for SNMP Advisory Team (the Advisory Team) was formed to provide a single recommended approach for SNMP evolution. The technical starting point for this Working Group will be the recommended approach provided by the Advisory Team.

This approach provides for the convergence of concepts and technical elements of V2u and V2*. The SNMPv3 Working Group is not starting new work and will use as many concepts, technical elements and documentation as practical from the V2u and V2* activities. Previous delays in providing a single standard for the next generation of SNMP core functions dictate that the Working Group move forward as quickly as possible to document and publish Internet Drafts and RFC's. To this end, the Working Group will make use of as much existing documentation as practical. Additionally, functional changes beyond those needed to provide a single approach will be strongly discouraged.

Timely completion of a single approach for SNMPv3 is crucial for the continued success of SNMP. Recognizing the need for prompt completion, the following objectives are provided to the Working Group:

- accommodate the wide range of operational environments with differing management demands;

- facilitate the need to transition from previous, multiple protocols to SNMPv3;

- facilitate the ease of setup and maintenance activities.

Note: SNMPv3 planned specifications:

SNMPv3 Modules and Interface Definitions SNMPv3 Message Processing and Control Module Specification SNMPv3 Security Model Module Specification SNMPv3 Local Processing Mosule Specification SNMPv3 Proxy Specification

Goals and Milestones:



Post first SNMPv3 Internet-Draft, Modules and Interface Definitions.



Working Group meeting at Memphis IETF to discuss SNMPv3 recommended approach, discuss Working Group Charter and the plan for completion.



Post revised SNMPv3 Modules and Interface Definitions Internet-Drafts.



Post initial SNMPv3 Message Processing and Control Module Internet-Draft.



Post initial SNMPv3 Security Model Module Internet-Draft.



Finalize SNMPV3 Modules and Interface Definitions Internet-Draft and review other I-Ds at Munich IETF.



Post revised SNMPv3 Local Processing Module Internet-Draft.



Post revised SNMPv3 Security Model Module Internet-Draft.



Post revised SNMPv3 Message Processing and Control Module Internet-Draft.



Post initial SNMPv3 Proxy Specification Internet-Draft.



Submit SNMPv3 Modules and Interface Definitions to IESG for consideration as a Proposed Standard.



All SNMPv3 specifications submitted to IESG for consideration as Proposed Standards.

Jul 98


Testing of interoperability between independent implementations of SNMPv3 core specifications.

Jul 98


Post the initial Internet Draft of the Intro document.

Aug 98


Post initial Internet Drafts for updating the SNMPv3 core specifications.

Aug 98


Post initial version of the Coexistence document as an Internet-Draft.

Aug 98


SNMPv3 Working Group Meeting at 42nd IETF.

Sep 98


Post revised version of the Intro document Internet-Draft.

Sep 98


Post revised version of the Coexistence document as an Internet-Draft.

Oct 98


Complete Working Group actions on revisions to core specifications and forward documents to the IESG for consideration as Draft Standard RFCs.


Request For Comments:







Introduction to Version 3 of the Internet standard Network Management Framework



An Architecture for Describing SNMP Management Frameworks



Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)



SNMPv3 Applications



User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)



View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

Current Meeting Report

SNMPv3 Working Group
Russ Mundy (Chair)
Shawn A. Routhier (notes)

As normal we started with some opening remarks from Russ (our chair), particularly asking for thoughts and comments on v3 deployment as well as some agenda bashing.

The first item on the agenda was dealing with the open items for the revisions to 1905 - 1907. The remaining items fall into two classes "straw" and "open". The consensus of the meeting was to determine if there were any objections to the "straw" items and to find solutions for the "open" items. In general, the "straw" items were accepted (list to follow). However in subsequent discussions on the mailing list it was not clear that all of the strawman positions were understood.

The item numbers as well as descriptions of the problems and suggested solutions may be found at: ftp://amethyst.bmc.com/pub/snmpv3/Update567/index.html

1905-5 - section 1.1, The note on terminology needs to be rewritten or replaced. Strawman => delete section 1.1. Agreement to delete affected sections

1905-6 - section 2.1, The section on roles of protocol entities can be dropped if we consistently use the terminology of the architecture. Strawman => clone a minimal amount of text from architecture. Agreement to delete affected sections

1905-8 - section 2.3, Is section 2.3 still required? Agreement to delete affected sections

1905-12 - section 3, get rid of SMI imports. There was a brief discussion of what the problem is. The goal was to make 1905 a stand- alone document which would require incorporating necessary sections of the SMI into 1905. This was also discussed in Oslo without a conclusion (at least one that could be documented from the notes).

Several people believed that including the text rather than importing the types from the SMI is required to loosen the coupling between the various documents while others don't feel the documents should be decoupled in such a fashion that the SMI is the glue that ties the other documents together. It was also suggested that the only way to get the desired separation would be to drop the suggested stuff and use "any". Not surprisingly, there was some significant disagreement about this statement. Lastly it was also pointed out that if new types are added in the future then the document would need to change again and so it can be avoided for now.

In the end, a show of hands was requested. There seems to be about a 2:1 ratio to leave it as it is with many people not expressing an opinion.

1905-13 - page 6, SMI data types in protocol formats Agreement to use an integer with a range specification from -2g to 2g for the message id.

1905-16 - section 4.1, do the descriptions of request-ids need changes to adapt to SNMPv3 msgID? There was some discussion about whether the two ids should match. Agreement to leave it alone

1905-22 - page 13, correct error in last response in example. Agreement to correct error in last response in example

1906-08 - section 4, why use 484 as a minimum size? Some discussion about using greater values. Agreement that systems must allow 484 and should use 1500

1906-18 - section 2, Should a TC and object id be added for IPv6? There was some discussion about where such information should go. If it should be in this document or in the endpoint mib or somewhere else. Agreement that it should go in a different document, with the AD suggesting that while it isn't required that the other document get done it would be a good idea.

1907-01 page 1, fix the title to not include "for version 2". Suggestion to change the title to: Management Information Base for the Simple Network Management Protocol

1907-02 section 1, rewrite introduction. [Ed Note: I believe this is the correct item, my notes had an incorrect item number (01) but 02 looks like the correct item.] Agreement to rewrite the introduction to remove references to SNMPv2

There was then discussion about the schedule for the specifications. The desire was to revamp the documents as quickly as possible, as such an extract of the notes was sent to the documents editor with a desire to have a last call on the mailing list. The plan is to have a last call for the information on the update web site (i.e., ftp://amethyst.bmc...) expected to start on 11/19 and last for 2 weeks. When the update changes are declared finished, they will be incorporated into new Internet Drafts that are intended to become the RFCs to be approved as full standards.

We then moved on to the coexistence document. Last call for this document closed on November 2 and had 2 messages most of which were editorial.

A short summary will be submitted to the mail list. This will include if the ids should be sent to the mailing list again or if the changes can be included an the ids sent forward. The changes should be in before the end of November.

The next part of the meeting dealt with reports on v3 deployment experience. If you have a report you would like to share (possibly with some sanitization) please send it to: snmpv3@list.tislabs.com or mundy@tislabs.com

It was also suggested that as vendors ship v3 for the first time, they make some sort of announcement - possibly via Juergen's page: http://www.ibr.cs.tu-bs.de/projects/snmpv3/. If available, information about end users would be useful as well as information about the implementations.

cisco will be including SNMPv3 with IOS 12.0(6)S and higher.

There is a small test bed in NAI labs.

Wes Hardaker (wjhardaker@ucdavis.edu) on the UCD-SNMP Deployment. The UCD (UC Davis) SNMP with support for SNMPv3 was released on August 23rd. Since then the distribution includes 6000 down loads from the home FTP site and an inclusion in the Redhat Linux 6.1 distribution. There are more distributions in the pipeline. However, the usage of SNMPv3 in particular is hard to estimate. They believe it to be quite small currently (less than 100) with many users suggesting they will use it soon. They believe that many users are waiting for other pieces of the users environment to become v3 compliant first.

Some common issues they have seen are that the added complexity does slow the adoption down some and that the initial USM configuration is difficult in large numbers. Key localization was specifically mentioned as part of the difficulty.

Russ Mundy (mundy@tislabs.com) TIS/NAI is in the process of deploying SNMPv3, mostly using the UCD code base. It is difficult to get information about various products.

This concluded the scheduled presentations and the comments/discussion from the crowd were requested.

The issue of key (password) configuration was raised, when potential users realize how hard it is they become less interested in security. One suggestion was that some features, such as reports, may be allowed to be turned off. This would be iffy from a security standpoint but would make configuration and deployment easier for the end user.

Jeff Case (case@snmp.com) described the efforts involved in the second release of their product. They didn't have any problems with interoperability between older and newer code. They did find that key management required a solution and put together a java based program to allow a manager to configure a set of devices at one time rather than one at a time. They have also heard of people waiting for the coex document so they could use the community table from a standard rather than from a private MIB.

Finally Jeff pointed out that the cisco release tree that includes the v3 features doesn't include features that are in a different tree and customers are choosing the features in the other tree (stable routing for example). It was also pointed out by other folks that not all of the product line includes v3 yet but that it should be out across more of the product line soon. One reason for this arrangement in cisco is that SNMPv3 is not yet classed as stable.

Several other vendors mentioned plans for having at least some support for SNMPv3 in the future. These vendors include Verio and Pacific Softworks.

As many vendors have implemented SNMPv3 but aren't shipping it yet the discussion turned to questions about how SNMPv3 could be promoted (as in marketed).

One proposal was to have a showcase such as "SNMPv3 in the Enterprise". This would be the next step from the Interop SNMPv3 showcases. Stories from entities that have deployed SNMP would be collected and presented somewhere (probably a trade show). One estimate put the minimum time to do such a showcase at 6 months.

A second proposal was to have people show support for SNMPv3 by writing white papers, creating web sites and speaking at various events (trade shows etc). The community might help with the last by forming a speaker bureau. Some folks are already doing some of the above and are seeing some excitement about SNMPv3 with some end users pushing their vendors to supply SNMPv3 - in other words some of the support is already there the community may simply need to do a better job of advertising it.

There was a short digression into how much deployment experience we need for the promotion of the specification. In general folks (including the chair) seemed to feel that while we might have enough to satisfy the letter of the law we probably want and need more to satisfy the spirit. Russ will need to get together with the ADs to see what is required.

It was pointed out that we have heard about several command responder applications (previously agents) but not so much about command generators (previously managers). Some examples of command generators using SNMPv3 are: HP Open View in conjunction with some code from Snmp Research, HP itself is not yet selling SNMPv3 capability, OSI Netexpert and Nerve Center as well as some applications written by ISPs for themselves. (Once again see Juergen's page for other information).

In summary: there are a number of entities using SNMPv3 in the field but we don't have any good specific data about them. Russ asks for information again, especially about end users. It was also suggested that the SNMPv3 community might get some information from the broader ops area (to which we belong), one option would be to send requests to an ops area mailing list.

Other proposals (as time permits)

Currently there are three crypto documents that the authors would like to see taken up by the working group. Although these are not currently items for the Working Group, the chair encourages WG members to review the IDs and provide comments to the authors of these documents.

Ken Hornstein - The Kerberos Security Model for SNMPv3 draft-hornstein-snmpv3-ksm-00.txt

Ken started KSM at the Minneapolis IETF meeting. After getting some positive feedback, he submitted it as a draft before Oslo. As yet he hasn't received any comments on it. A sample implementation is still in progress and is about 3/4 finished. It is based on the UCD SNMP codebase. Currently it can send an auth request from a manager to an agent and
receive the reply. Work on hooking up the access control framework is
ongoing. They also haven't done anything about traps yet.

There are several problems that have appeared:
1) The current draft doesn't authenticate the whole message, the header is not included.
2) Not all of the info needed by Kerberos are passed down via the security model layer.

(2) caused a discussion about ASIs vs APIs and if there was anything we could do to make it clear that they may be different. As it seems the implementors aren't reading all of the documents it's not clear we can do anything though two ideas were mentioned. The first was to add some ... to the argument list the second was to rename them to "NOTANAPI" instead of "ASI".

Mike StJohns - SNMPv3: Kickstart & KeyChange

Kickstart is a way to securely configure an entities USM parameters after the key has been compromised without physically visiting the entity. In some situations with either large numbers of entities or entities that aren't physically accessible it may be impossible to visit the entity physically.

The key change section proposes a new TC that allows for the use of Diffie-Helman key agreement protocol to populate the new keys. This TC would be used as the type for four new objects that would augment the USM User Table. These objects would match the current four key change objects. There would be no changes to USM or VACM.

An example of the key change was given.

The kickstart section includes a new mib table that is populated as a side effect of the configuration. The table is publicly readable and contains agent and manager DH public numbers as well as security names. The USM user table is then populated with derived auth and priv keys.

An example of kickstart was given.

Some of the open issues involve the secret keys being randomly selected rather than chosen and the possibility of man in the middle attacks.

Some of the issues driving this work are the need to manage large number of devices securely and that the current security service still inadequate - especially absence of forward secrecy.

The next steps for this work are: Mike asking that the draft be published as an experimental rfc and suggesting that the work be moved into main stream as one of the next work items for the SNMPv3 group.

There was some discussion about deployment plans for this, there don't seem to be current plans for it. It was noted that DOCSIS will require require SNMPv3 and need coex and some companies will start turning off v1 and v2 as v3 is deployed. IKE was mentioned but nobody knows of it being used in this area yet. Lastly there was some discussion on (the lack of) perfect forward secrecy and in SNMPv3.

Olafur Guomundsson - SNMPv3 3DES David Reeder (dreeder@tislabs.com)

This was an attempt to write a draft on using 3DES as a USM transform. Primarily it was at attempt to exercise the USM specification and check if it is extensible to new crypto transforms as well as starting the process of specifying transforms that are more secure than DES. They learned that: the USM document can be updated to include more transforms

USM as specified does not allow the expression of keys that are longer than 128/160 bits (3DES in USM requires up to 168 + 64 bits for keying) the output of the password to key scheme is limited to the hash length of the underlying digest algorithm

They proceeded to change the procedure of password to key scheme to generate more bits and to extend the USM MIB to add an object id for the USM 3DES protocol.

It was felt that this would probably augment rather than replace the current work.

Danny Raz <raz@lucent.com> gave a talk on network address translator for SNMP draft-ietf-nat-snmp-alg-02.txt. This was a very brief talk due to a lack of time.

Problems occur when two or more private networks all using the same address space managed are managed from the same place (perhaps due to two (or more) companies merging or the use of a third party network service provider. The suggested overall solution is to insert a NAT in the path and translate addresses as necessary. A new version of the draft is to be released in mid-December. The current draft doesn't include SNMPv3, but it will be addressed in the future. There also appear to be two versions with one including support for handling TDOMAIN and TADDR while the other doesn't.

Amongst other things this is a request for help to identify what may or may not be able to be solved including identifying limitations of this approach.

IP Tunneling was also brought up and it was pointed out it might also have problems differentiating IP addresses.


SNMPv3 Working Group