2.6.4 Integrated Security Model for SNMP (isms)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-02

Chair(s):

Ken Hornstein <kenh@cmf.nrl.navy.mil>
Juergen Quittek <quittek@netlab.nec.de>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: isms@ietf.org
To Subscribe: isms-request@ietf.org
In Body: in body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html

Description of Working Group:

Version 3 of the Simple Network Management Protocol (SNMPv3) was
elevated to Internet Standard in late 2002 and added security to the
previous versions of the protocol. Although the enhanced protocol
is secure, operators and administrators find that deploying it can
be problematic in large distributions. This is due primarily to two
synchronization problems. The first is the addition of yet another
authentication system specific to SNMPv3 that needs to be maintained
across all networking devices. Most of these devices already
contain local accounts and/or the ability to negotiate with
authentication servers (e.g. RADIUS servers). However, SNMPv3 does
not make use of these authentication mechanisms, and this causes
additional synchronization burdens. The second issue found with
deploying SNMPv3 is that distributing and maintaining View-based
Access Control Model (VACM) rules is also difficult in large-scale
environments.

The ISMS working group will focus on finding and identifying a solution
for the first of the two above mentioned problems: creating a security
model for SNMPv3 that will meet the security and operational needs of
network administrators. The solution should maximize useability in
operational environments to achieve high deployment success and at
the same time minimize implementation and deployment costs to
minimize the time until deployment is possible. The work will
include the ability to make use of existing and commonly deployed
security infrastructure. The following security infrastructures
will be considered by the working group as potential existing
authentication infrastructures to make use of within the new
security model. The solution will hopefully be able to be integrated
with multiple of these user databases although it is expected that
one will be mandatory.

- Local accounts
- SSH identities
- Radius
- TACACS+
- X.509 Certificates
- Kerberos
- LDAP
- Diameter

A solution must not modify the other aspects of SNMPv3 protocol as
defined in STD 62 (EG, it must not create new PDU types). It should
also be compliant with the security model architectural block of
SNMPv3, as outlined in RFC 3411. And if at all possible, it should
also not change any other protocols either.

The working group will begin focusing on initial proposals, which
must be submitted for consideration by the Internet-Draft cut-off
date for the 61st IETF (Oct 19th, 2004). Documents submitted for
consideration need not be well-polished but are expected to
adequately describe the proposed model enough that working group
participants can adequately understand them to make an informed
decision when considering it along with the other candidates. The
working group will select one forward path from all the proposals
submitted by the cut-off date. If no such selection is made by the
end of March, 2004 then the working group will be closed down.

Work Items

- Choose a technical direction for the working group to focus on.

Goals and Milestones:

Done  Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution
Mar 05  Decision about which solution approach the WG will focus its efforts on
Mar 05  2005 Working group will recharter to include publication goals or shutdown if no consensus on a technical direction is reached by this time

Internet-Drafts:

  • draft-ietf-isms-proposal-comparison-00.txt

    No Request For Comments

    Current Meeting Report

    ===========================================
    Minutes of the ISMS session at IETF 62
    Monday March 7, 19:30 h - 22:00 h
    ===========================================

    Integrated Security Model for SNMP working group
    Chairs: Ken Hornstein <kenh@cmf.nrl.navy.mil>
    Juergen Quittek <quittek@netlab.nec.de>


    0. Session Summary
    1. ISMS WG Status
    2. Comparison of Proposals
    3. ISMS goals and problems with USM
    4. Wrap up


    ----------------
    Discussed Internet drafts

    Comparison of Proposals for Integrated Security Models for SNMP
    (Simple Network Management Protocol)
    http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt

    Transport Layer Security Model (TLSM) for the Simple Network
    Management Protocol version 3 (SNMPv3)
    http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt

    A Session-Based Security Model (SBSM) for version 3 of the Simple
    Network Management Protocol (SNMPv3)
    http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt

    External User Security Model (EUSM) for version 3 of the Simple
    Network Management Protocol (SNMPv3)
    http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt

    ----------------
    0. Session Summary

    The ISMS evaluation team had produced an I-D comparing the proposed solutions TLSM, EUSM, and SBSM. The team gave the recommendation to choose EUSM as starting point for standardization work in ISMS. However, EUSM uses EAP and few days before the meeting, the ADs discovered that this conflicts with the EAP applicability statement in RFC 3748.

    The WG discussed this constraint extensively without reaching consensus on how to react. In order to still progress further, the WG decided to make a decision on the target ISMS architecture first, before closing the protocol issue. The chairs and the evaluation team will post a description of the alternative architectures that have been discussed and will try to achieve consensus on a single ISMS architecture until end of April. Then discussion on a new ISMS charter will start, that must be completed at IETF63. Otherwise the WG will be closed.

    ----------------
    1. ISMS WG Status (Juergen)

    Three proposal have been submitted as proposals for an ISMS: SBSM, EUSM, and TLSM. An evaluation team analyzed them and delivered a comparison and a recommendation as an internet draft. There was no clear winner among, but the evaluation team recommended starting with EUSM and applying a set of modifications to it. It was appreciated that EUSM does implement a key exchange protocol by itself, but re-used an existing one, the EAP.

    The week before the IETF it turned out that this choice was not a good one. In RFC 3748 there is an applicability statement for EAP that limits EAP applications to network access authentication, which is not the case for EUSM. The ADs decided that the WG cannot use EAP because of this.

    [?] Can someone in the room explain why EAP should not be applied.

    [Eric Rescorla] There are two orthogonal issues: One is the integration of a security protocol with the SNMP stack. The second is which protocol is acceptable for key exchange. There are several other protocols that potentially can be used instead of EAP.

    [?] EAP was chosen for EUSM becasue it works well with AAA protocol

    [Kaushik Narayan] We have a process of evaluating the approach and EUSM was recommended. There will be ways of using other protocols, but is EAP completely out of the game or may it still be used with some restrictions?

    [?] I am not convinced that it is not a good idea to use EAP.

    [Sam Hartman] I would be very concerned about uses of EAP that are involving interactions with the radius server and the person initiating the request. The EAP applicability statement clearly exclude the application in ISMS

    [Wes Hardaker] Let's decide on the architecture first independent of protocols. All three proposals are going to use radius. Let's first discuss about whether we want in-band key exchange or off-band key exchange.

    [Eric] There are four ways to move forward: (1) no authentication (2) some other framework besides EAP, (3) we really want to use EAP and try to convince the ADs, (4) we design something completely new.

    [?] The requirements for ISMS look like IKE would be a perfect solution.

    [Sam] IKEv2 also has an applicability statement. IKEv2 is only to be used for IPsec.

    [Juergen] I also see three options: we try to push EAP hardly, we go on with the recommendation but replace EAP by something else, or we start another round of proposals and recommendation. Shall we go for another round of proposal and evaluation until the next meeting?

    [Eric] We can either first work on the EAP issue or first on the architecture issue.

    [Sam (not speaking as AD)] I think TLSM would be the best choice. It solves all problems with established and appropriate means.

    [Kaushik] TLS does not address authentication for anything else than certificates or shared secrets.

    [Eric] TLSM is a framework, not a protocol. You can wedge any underlying transport security mechanism underneath.

    [Wes] Re-use of existing protocols is limited if we continue using UDP for SNMP.

    [Sam] In the UDP space we have DTLS.

    [David Nelson] If we talk about re-use, we should think about re-using what operators already have installed.

    [Dave Harrington] TCP is fine for SNMP, but there must be a fallback to UDP possible.

    [Sam] If you do the architecture decision first, please make sure that later implementation constraints will not make you change you decision.

    [Sam] I'm deeply concerned anywhere where clients talk to radius servers.

    [Wes] We should discuss on the architecture first, rather than doing another round of proposal and evaluation until the next meeting.

    Juergen asked for handraising. There was a clear majority of the session participants in favor of deciding on the architecture first. It was agreed to decide on the architecture until end of April.

    [Wes] The evaluation team and/or the chairs should summarize the architecture issues in order to structure the decision.


    ----------------
    2. Comparison of Proposals (Lakshminath Dondeti)

    draft-ietf-isms-proposal-comparison-00.txt

    Lakshminath summarized the architectural differences of the three proposals and explained the list of recommendations given in the document.


    ----------------
    3. ISMS goals and problems with USM (Dave Perkins)

    Dave summarizes the WG goals and discusses weaknesses of USM. for potential ISMS solution he discussed pros and cons of re-using USM.

    ----------------
    4. Wrap up

    The WG has to decide on an architecture until April and on a new charter until August. the milestones in the current charter will be updated accordingly.

    Slides

    ISMS WG Status
    Comparison of Proposals for Integrated Security Models for SNMP
    ISMS March 2005 IETF