[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
ISMS                                                       U. Blumenthal
Internet-Draft                                         Intel Corporation
Expires: August 17, 2005                                      L. Dondeti
                                                         Nortel Networks
                                                         R. Presuhn, Ed.
                                                   R. Presuhn Consulting
                                                             E. Rescorla
                                                              RTFM, Inc.
                                                       February 13, 2005

    Comparison of Proposals for Integrated Security Models for SNMP
                  (Simple Network Management Protocol)

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 are draft documents 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 "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


Blumenthal, et al.       Expires August 17, 2005                [Page 1]

Internet-Draft          ISMS Proposal Comparison           February 2005

   Although the Simple Network Management Protocol (SNMPv3) is secure,
   operators and administrators have found that deploying it can be
   problematic in large distributions, due to a lack of integration
   between its User-Based Security Model (USM) and other authentication
   and user management infrastructure.  This memo contains an evaluation
   of three proposals for an integrated security model for SNMP, and,
   based on these proposals, suggests how the ISMS (Integrated Security
   Model for SNMP) working group might move forward.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Terms and Abbreviations  . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Background . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2   Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3   Operational Scenarios  . . . . . . . . . . . . . . . . . .  6
     2.4   Proposals Considered . . . . . . . . . . . . . . . . . . .  7
       2.4.1   User Security Model  . . . . . . . . . . . . . . . . .  7
       2.4.2   External User Security Model . . . . . . . . . . . . .  8
       2.4.3   Session-Based Security Model . . . . . . . . . . . . . 10
       2.4.4   Transport-Layer Security Model . . . . . . . . . . . . 11
   3.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 12
     3.1   Architectural View . . . . . . . . . . . . . . . . . . . . 13
     3.2   Supported Security Infrastructures . . . . . . . . . . . . 13
     3.3   Integration with VACM  . . . . . . . . . . . . . . . . . . 13
     3.4   Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 14
       3.4.1   Session Keys . . . . . . . . . . . . . . . . . . . . . 14
       3.4.2   Number of Security Levels per Session  . . . . . . . . 14
       3.4.3   User Caching . . . . . . . . . . . . . . . . . . . . . 15
     3.5   Need for Initial Shared Secrets  . . . . . . . . . . . . . 15
     3.6   Reuse of Existing Security Protocols . . . . . . . . . . . 15
     3.7   Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 21

Blumenthal, et al.       Expires August 17, 2005                [Page 2]

Internet-Draft          ISMS Proposal Comparison           February 2005

1.  Introduction

   SNMPv3 became a full Internet Standard in late 2002, adding security
   to the previous versions of the protocol.  Although the enhanced
   protocol is secure, operators and administrators have found that
   deploying it can be problematic in large distributions, due to a lack
   of integration between USM and other authentication and user
   management infrastructure.  This memo contains an evaluation of three
   proposals for an integrated security model for SNMP, and, based on
   these proposals, suggests how the ISMS working group might move
   forward.  Readers should be reminded that, in accordance with
   [RFC2418] section 6.5, the working group is free to adopt, reject,
   ignore or modify these recommendations in whatever way it sees fit.

1.1  Terms and Abbreviations

   The following list defines the terms and abbreviations used here,
   and, where appropriate, provides references to further information on
   the relevant concepts.

      AAA:        Authentication, Authorization and Accounting [RFC2903]
      CLI:        Command Line Interface
      Diameter:   (not an acronym) [RFC3588]
      DTLS:       Datagram Transport Layer Security [I-D.rescorla-dtls]
      EUSM:       External User Security Model
      IKE:        Internet Key Exchange [RFC2409]
      IPsec:      IP Security [RFC2401]
      Kerberos:   a third-party authentication protocol defined in
      LDAP:       Lightweight Directory Access Protocol [RFC2251]
      MAC:        Message Authentication Code
      PDU:        Protocol Data Unit
      RADIUS:     Remote Authentication Dial In User Service [RFC2865]
      Session:    Not quite a connection, nor an association, and not to
                  be confused with a CLI session, we use the term
                  session here to refer to a sequence of exchanges
                  between two SNMP engines making on behalf of a single
                  user and secured by the same key, as well as any PDU
                  exchanges needed to establish or tear down the
      SBSM:       Session Based Security Model
      SNMP:       Simple Network Management Protocol [RFC3410]
      SSH:        Secure Shell protocol [I-D.ietf-secsh-architecture]

Blumenthal, et al.       Expires August 17, 2005                [Page 3]

Internet-Draft          ISMS Proposal Comparison           February 2005

      TACACS+:    Terminal Access Controller Access Control System
                  (plus) [RFC1492]
      TCP:        Transmission Control Protocol [RFC0793]
      TLS:        Transport Layer Security protocol [RFC2246]
      TLSM:       Transport Layer Security Model [I-D.schoenw-snmp-tlsm]
      UDP:        User Datagram Protocol [RFC0768]
      USM:        User-Based Security Model [RFC3414]
      VACM:       View-Based Access Control Model [RFC3415]

2.  Overview

   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 have found that deploying it
   could be problematic in large distributions.  There have been two
   major sources of difficulty.  First, most networking devices already
   contain local accounts or the ability to negotiate with
   authentication servers, such as RADIUS servers.  However, SNMPv3 does
   not make use of these authentication mechanisms, but instead adds its
   own SNMPv3-specific authentication system, which needs to be
   maintained across all networking devices.  Secondly, the distribution
   and maintenance of View-based Access Control Model (VACM) rules is
   also difficult in large-scale environments.

2.1  Background

   In principle, SNMP has modular security, with communications security
   being provided via different "security models".  In practice, SNMP
   security is done via the "User-based Security Model" [RFC3414], which
   is essentially per-message encryption and authentication inside of
   SNMP.  USM keying is based on per-user shared keys, used between SNMP
   engines that need to communicate securely on behalf of management
   applications.  (The traditional terms "manager" and "agent" are not
   particularly helpful, since both kinds of applications may make use
   of a given SNMP protocol engine at the same time.) Key localization
   techniques are used to minimize the impact of the compromise of a
   shared key.

   There are two major sources of discontent with USM:

      1.  Key management with manual keying is extremely difficult in
          any system.  SNMP is no different.  (major reason)
      2.  USM anti-replay protection is limited by design (minor
          reason).  A message may be replayed within a 150 second
          window.  Note that for set operations where ordering and
          non-duplication can be important, this can be largely
          mitigated by the use of TestAndIncr [RFC2579] objects.

Blumenthal, et al.       Expires August 17, 2005                [Page 4]

Internet-Draft          ISMS Proposal Comparison           February 2005

   A number of alternative designs have been proposed to improve SNMP
   security.  We discuss three here:

      EUSM: External User Security Model [I-D.kaushik-snmp-external-usm]
      SBSM: Session Based Security Model [I-D.hardaker-snmp-session-sm]
      TLSM: Transport Layer Security Model [I-D.schoenw-snmp-tlsm]

   Evaluating these documents is difficult because they vary along two
   primary axes:

      1.  Architectural -- each of these designs is very different in
          terms of how it integrates with the SNMP architecture.
      2.  Features -- each design provides some support for automatic
          key management, but with a fair amount of variety in the kinds
          of credentials supported.

   To a first order, these concerns are orthogonal.  The intent of this
   document is to evaluate the merits of various architectural
   approaches, without regard to the specific implementation details of
   the authentication mechanisms proposed in these drafts.  In order to
   do this, we will confine the following discussion to idealized
   architectural sketches of the approach used by each protocol.  We
   begin by describing the existing User-based Security Model, both for
   reference and to simplify comparison of the other schemes.

2.2  Goals

   The ISMS (Integrated Security Model for SNMP) working group was
   chartered to identify 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 goals were to maximize usability in operational
   environments to achieve high deployment success and at the same time
   minimize implementation and deployment costs to minimize the time
   until deployment would be possible.  The ability to make use of
   existing and commonly deployed security infrastructure was a
   requirement, as was consideration of the following as potential
   existing authentication infrastructures to make use of within the new
   security model, with at least one being mandatory:

      *  Local accounts
      *  SSH identities
      *  RADIUS
      *  TACACS+
      *  X.509 Certificates
      *  Kerberos
      *  LDAP

Blumenthal, et al.       Expires August 17, 2005                [Page 5]

Internet-Draft          ISMS Proposal Comparison           February 2005

      *  Diameter

   The working group's charter constrains the solution.  It must not
   modify the other aspects of SNMPv3 protocol as defined in STD 62.  It
   should also be compliant with the security model architectural block
   of SNMPv3, as outlined in [RFC3411].  Finally, it should also not
   change any other protocols.

   In addition to goals and requirements given in the working group
   charter, discussion on the mailing list and in working group meetings
   helped identify additional points to consider in evaluating

      *  Must be at least as secure as USM [RFC3414].
      *  Must not preclude the use of USM [RFC3414], particularly if
         network instability could cause problems for the proposed
      *  Must be able to work with VACM.
      *  The protocol itself should support multiple security
         infrastructures, but an implementation may support some subset
         of these.
      *  Must not break basic device discovery.  (Retaining USM support
         would satisfy this goal.)

   In the documents and on the mailing list, some additional potential
   goals and requirements have been mentioned, but did not seem to enjoy
   widespread support.  This does not mean that the evaluation team
   contests that they may be desirable; it simply means that these were
   given secondary importance in our evaluation.  These include:

      *  support for anonymous secured access (to ensure integrity of
      *  implementation impact
      *  deployment impact
      *  time to market
      *  stronger reorder / replay protection

2.3  Operational Scenarios

   How well proposals satisfy the goals described above can be evaluated
   by looking at specific operational scenarios or use cases.  Ones
   mentioned on the mailing list include:

      *  deploying a new device, such as a router
      *  adding access for a new user
      *  revoking access for a user
      *  changing a user's secrets

Blumenthal, et al.       Expires August 17, 2005                [Page 6]

Internet-Draft          ISMS Proposal Comparison           February 2005

   In looking at each of these cases, one must consider what steps are
   needed with classic USM, which steps under the proposal under
   evaluation would be needed anyway (in order to support, for example,
   a CLI), how much of the classic USM work could be avoided under the
   proposal, and what additional configuration is needed to support the

2.4  Proposals Considered

   This section provides a brief review of USM, and then gives an
   overview of each of the proposals.

2.4.1  User Security Model

   The User-based Security Model [RFC3414] is a simple shared secret
   scheme.  The operator configures secrets in the SNMP engines used by
   management applications.  (Management applications include things
   traditionally considered "managers" and "agents".) These secrets may
   be "localized keys", computed from a passphrase known only to that
   user.  These independent authentication and encryption keys are used
   to secure communication.  Traffic may be authenticated, or
   authenticated and encrypted.  The protocol also supports
   unauthenticated unencrypted exchanges, but they are not of interest

   +------------------------+                +------------------------+
   |        Manager         |                |        Managed         |
   |        Computer        |                |        Device          |
   | +--------------------+ |                | +--------------------+ |
   | |    SNMP Engine     | |                | |     SNMP Engine    | |
   | |                    | |                | |                    | |
   | |                    | | <------------> | |                    | |
   | |          +-------+ | |                | | +-------+          | |
   | |          |  USM  | | |                | | |  USM  |          | |
   | |          +-------+ | |                | | +-------+          | |
   | +--------------------+ |                | +--------------------+ |
   +------------------------+                +------------------------+

                                Figure 1

   With USM security, the USM is part of the SNMP implementation.
   Messages to be protected are passed through the USM for
   transformation (encryption and/or authentication).  When protected
   messages are received, they are passed through the USM for processing
   (decryption and/or authentication).  The SNMP engine must keep track
   of whether a message had been encrypted and authenticated in order to
   make access control decisions.

Blumenthal, et al.       Expires August 17, 2005                [Page 7]

Internet-Draft          ISMS Proposal Comparison           February 2005

   As previously noted, this scheme has two disadvantages.  First, even
   though all the localized keys for a given user in an administrative
   domain may be generated automatically from a single passphrase,
   device and user churn can still make it difficult to configure.
   Secondly, the particular message protection scheme, by design, does
   not provide replay protection inside a 150 second window.  Being able
   to perform management operations while the underlying protocols were
   experiencing packet loss, duplication, or re-ordering was considered
   more important than protecting against replay attacks within a 150
   second window, particularly since such attacks can be blocked by
   using a TestAndIncr [RFC2579] object to protect set requests which
   could do damage if replayed within the 150 second window.

2.4.2  External User Security Model

   The External User Security Model [I-D.kaushik-snmp-external-usm]
   replaces USM's key management but leaves the USM transport alone.
   EUSM assumes that an external key management process will be
   co-resident with SNMP engines, and will install the keys, as with

   +------------------------+                   +----------------------+
   |        Manager         |                   |        Managed       |
   |        Computer        |                   |        Device        |
   |                        |                   |                      |
   |            +---------+ |                   | +--------+           |
   |            | Key     | |  Key establish    | | Key    |           |
   |            | Mgmt    | |<----------------->| | Mgmt   |           |
   |            +---------+ |                   | +--------+           |
   |                 ^      |                   |     ^                |
   | +---------------|----+ |                   | +---|--------------+ |
   | |   SNMP Engine |    | |                   | |   | SNMP Engine  | |
   | |               |    | |  Message traffic  | |   |              | |
   | |               v    | | <---------------> | |   v              | |
   | |          +-------+ | |                   | | +-------+        | |
   | |          |  USM  | | |                   | | |  USM  |        | |
   | |          +-------+ | |                   | | +-------+        | |
   | +--------------------+ |                   | +------------------+ |
   +------------------------+                   +----------------------+

                                Figure 2

   In EUSM, the SNMP engines establish keys using the external key
   management system.  Those keys are then passed to the USM, and create
   (or at least key) users (or pseudo-users).  From that point on,
   ordinary USM message protection is used.

   One advertised advantage of EUSM is tight integration with

Blumenthal, et al.       Expires August 17, 2005                [Page 8]

Internet-Draft          ISMS Proposal Comparison           February 2005

   pre-existing network AAA systems such as RADIUS and DIAMETER.  The
   general picture is shown below: the key management processes
   coordinate with the AAA server to perform the key agreement exchange.

                                |   AAA   |
                      --------> | Server  |<--------|
                      |         +---------+         |
                      |                             |
                      |                             |
   +------------------|-----+                   +---|-----------------+
   |        Manager   |     |                   |   |    Managed      |
   |        Computer  |     |                   |   |    Device       |
   |                  v     |                   |   v                 |
   |            +---------+ |                   | +--------+          |
   |            | Key     | |  Key establish    | | Key    |          |
   |            | Mgmt    | |<----------------->| | Mgmt   |          |
   |            +---------+ |                   | +--------+          |
   |                 ^      |                   |     ^               |
   | +---------------|----+ |                   | +---|-------------+ |
   | |   SNMP Engine |    | |                   | |   | SNMP Engine | |
   | |               |    | |  Message traffic  | |   |             | |
   | |               v    | | <---------------> | |   v             | |
   | |          +-------+ | |                   | | +-------+       | |
   | |          |  USM  | | |                   | | |  USM  |       | |
   | |          +-------+ | |                   | | +-------+       | |
   | +--------------------+ |                   | +-----------------+ |
   +------------------------+                   +---------------------+

                                Figure 3

   It's important to recognize that this is not an architectural
   advantage.  Whether an AAA server is involved or not is completely
   orthogonal to the external key management design.  One could use this
   general design with or without AAA integration.  In order to reduce
   diagram complexity, we will not show AAA integration for the other
   approaches, although it is in general as easy to add
   *architecturally* to one approach as to the others.

   The primary advantage of this scheme is that it has very little
   impact on the SNMP implementation.  Because the implementation
   already has the ability to accept externally specified (manual) keys,
   it is straightforward to modify the design to accept externally
   specified keys which are generated via an automatic key management
   process.  This is part of the reason why a similar design was chosen
   for IKE/IPsec.  EUSM also has the desirable feature of integrating
   very well with RADIUS, desirable due to its large market presence.
   An additional advantage, as well as a limitation of this approach, is

Blumenthal, et al.       Expires August 17, 2005                [Page 9]

Internet-Draft          ISMS Proposal Comparison           February 2005

   the extent to which it reuses USM, since at leaves USM's anti-replay
   mechanisms intact.

   This approach has several drawbacks.  The first is that it inherits
   the communications security limitations of USM with respect to replay
   attack.  The second is that it because the integration of the
   external key management module with the SNMP implementation is
   relatively loose, it can make policy setting confusing.  In
   particular, it could be difficult to coordinate users between various
   processes.  The coordination of permissions could likewise be a
   problem, but VACM coordination is out of scope of this effort, and
   none of the other proposals address this issue, which has been a
   substantial problem with IKE/IPsec.  An additional consideration is
   that it's not clear how this could be used with Kerberos, at least as
   Kerberos is normally used.

   A secondary problem is that it can be difficult for the key
   management system to give the USM and the rest of the SNMP
   implementation information about users.  Looking ahead to the
   integration of access control configuration, the ability to reuse the
   existing key management interfaces starts to be inadequate.  However,
   none of proposals do anything to address this, since almost all the
   user-specific information other than keys belongs to VACM.  This
   proposal's way of addressing policy integration by providing the
   user/group mapping for VACM seems to be a good tradeoff, giving
   dynamic authentication and integration with existing access control
   without excessive overhead.

2.4.3  Session-Based Security Model

   The Session-Based Security Model [I-D.hardaker-snmp-session-sm]
   addresses the first disadvantage by replacing the USM entirely.  The
   new security model (SBSM) is an integrated session establishment and
   messaging protocol.  When two network entities wish to communicate
   initially, SBSM performs a key agreement handshake to establish a
   session.  From then on, messages are protected inside of SNMP.  That
   is, the ciphertext and/or MAC data is encapsulated inside of an SNMP
   message, just as with USM and EUSM.

Blumenthal, et al.       Expires August 17, 2005               [Page 10]

Internet-Draft          ISMS Proposal Comparison           February 2005

   +----------------------+          +----------------------+
   |       Manager        |          |       Managed        |
   |       Computer       |          |       Device         |
   | +------------------+ |          | +------------------+ |
   | |   SNMP Engine    | |          | |    SNMP Engine   | |
   | |                  | |          | |                  | |
   | |                  | | <------> | |                  | |
   | | +-----+ +------+ | |          | | +------+ +-----+ | |
   | | | USM | | SBSM | | |          | | | SBSM | | USM | | |
   | | +-----+ +------+ | |          | | +------+ +-----+ | |
   | +------------------+ |          | +------------------+ |
   +----------------------+          +----------------------+

                                Figure 4

   This design allows the tightest coupling between the security system
   and the rest of the SNMP implementation.  Authentication information,
   such as user names and session lifetime constraints, can be easily
   passed between them.  This approach has the advantage of providing an
   extensible architecture and making it possible to integrate almost
   any authentication or privacy mechanism.

   The major disadvantage of this design is that because it is so
   tightly coupled to the SNMP implementation, it may require a fair
   amount of reinvention.  Indeed, the current SBSM design is a
   completely new security protocol.  In principle, one could use an
   existing protocol such as IKE or TLS, but encapsulate all the message
   traffic in SNMP in the same way as the current SBSM, but it's not
   clear that that design would be superior to TLSM (below).  In any
   case, going with SBSM would require a careful evaluation of the
   security protocol.

   An open issue here is how to tie whatever identity the this security
   model has for a user with the security name needed by VACM to do the
   user-to-group mapping.  If these need to be pre-configured in VACM,
   the value is diminished.

2.4.4  Transport-Layer Security Model

   The Transport Layer Security Model [I-D.schoenw-snmp-tlsm] simply
   rehosts all SNMP communications over a new secure transport.  The
   obvious choices here are TLS (for TCP) and DTLS (for UDP).  However,
   from an architectural perspective, any self-contained generic channel
   security mechanism (such as IPsec or SSH) would also be fine.  This
   produces a picture like the one below.

Blumenthal, et al.       Expires August 17, 2005               [Page 11]

Internet-Draft          ISMS Proposal Comparison           February 2005

   +------------------------+               +------------------------+
   |        Manager         |               |        Managed         |
   |        Computer        |               |        Device          |
   | +--------------------+ |               | +--------------------+ |
   | |    SNMP Engine     | |               | |     SNMP Engine    | |
   | |                    | |               | |                    | |
   | |                    | | <- - - - - -> | |                    | |
   | | +------+ +-------+ | |               | | +-------+ +------+ | |
   | | | TLSM | |  USM  | | |               | | |  USM  | | TLSM | | |
   | | +------+ +-------+ | |               | | +-------+ +------+ | |
   | +----^---------------+ |               | +-----^--------------+ |
   |      |                 |               |       |                |
   | +----v---------------+ |               | +-----v--------------+ |
   | |  Security layer    | | <-----------> | |   Security layer   | |
   | +--------------------+ |               | +--------------------+ |
   +------------------------+               +------------------------+

                                Figure 5

   With the TLSM architecture, there is a new security model, the TLSM,
   but it's effectively a shim.  All the heavy lifting is done by the
   generic security layer/protocol.  The TLSM's only job is to provide
   the user name and security level to the security layer and to collect
   the per-message security properties.  The downside to this is that
   the question of how the security layer's user names get mapped to
   security names for VACM is left open.  This can be addressed either
   by preconfiguration, which defeats the purpose of the proposal, or by
   borrowing something like the EUSM proposal's mechanism for emulating
   the security name to group mapping for VACM.

   From the network perspective, SNMP traffic secured with TLSM looks
   like every other kind of traffic secured with the underlying security
   layer.  The only indication that it is SNMP is (potentially) the
   choice of port number.

   TLSM allows reuse of standard communications security tools (e.g.,
   TLS) while allowing a reasonable amount of coupling between the
   security layer and the SNMP implementation.  However, it will likely
   be more work to integrate than EUSM and allow a less rich coupling
   than SBSM.

3.  Recommendations

   The evaluation team was unable to identify a clear winner among the
   three proposals.  Each of the documents contained some of the
   elements needed for a complete solution.  In part, this was due to
   the preliminary nature of the internet drafts that were available,
   and the different teams had fleshed out different elements of their

Blumenthal, et al.       Expires August 17, 2005               [Page 12]

Internet-Draft          ISMS Proposal Comparison           February 2005

   proposals in differing degrees of detail.

3.1  Architectural View

   The evaluation team recommends the inclusion of an architectural
   perspective, like that provided by the TLSM proposal, though, of
   course, adapted to the technical specifics of the agreed solution.
   In particular, it's important to spell out where the various bits
   come from that are needed for the message processing model and
   security model abstract service interfaces, as well as what goes into
   message wrappers and any inter-layer redundancies.  When
   authentication or encryption services are provided by other protocols
   outside SNMP proper, whether existing APIs provide these bits is an
   important consideration in gauging what the implementation effort
   would be.

   The SNMPv3 architecture goes to some length to avoid talking about
   managers and agents, and is instead described in terms of SNMP
   engines and applications.  This was motivated by practical
   considerations and implementation experience, not just architectural
   purity.  The evaluation team recommends that this working group
   maintain this perspective.

3.2  Supported Security Infrastructures

   The evaluation team recommends that the working group adopt an
   approach that can accommodate multiple security infrastructures
   concurrently.  The EUSM proposal was clearest in this regard and went
   into the greatest detail, though clearly still greater detail will be
   needed for an interoperable specification.  Note however that EUSM
   specifies integration with a specific authentication architecture,
   viz., AAA; we suggest the incorporation of a generic authentication
   architecture, with AAA as the case study.  Either the EUSM
   specification or an independent specification can then describe how
   Kerberos (or any other authentication architecture) might be
   integrated.  This is justified by the extreme diversity of security
   infrastructures currently in use, and the lack of compelling
   arguments justifying the selection of one to the exclusion of all

   The evaluation team also recommends, in the interest of
   interoperability, that the working group select a single
   mandatory-to-implement mechanism.  The evaluation team recommends
   RADIUS [RFC2865] for this purpose, due to its widespread use.

3.3  Integration with VACM

   The SNMP architecture in general recognizes that how a user is

Blumenthal, et al.       Expires August 17, 2005               [Page 13]

Internet-Draft          ISMS Proposal Comparison           February 2005

   identified in a particular security model may need to be mapped to a
   protocol-independent identifier, allowing integration of different
   authentication schemes, for example.  USM uses the
   usmUserSecurityName object to accomplish this.  The evaluation team
   recommends that ways to support such mappings be investigated, since
   none of the proposals directly addresses this issue.

   Dynamic authentication of users is not operationally sufficient,
   given how VACM works.  Requiring security administrators to
   pre-configure the vacmSecurityToGroupTable [RFC3415] for dynamically
   authenticated users would defeat the whole purpose of doing dynamic
   authentication.  Consequently, the evaluation team recommends the
   inclusion of something similar to the EUSM proposal's mechanism for
   conveying user-to-group mappings from the AAA-server-equivalent.
   This should not be confused with full-scale configuration of VACM,
   which is out of scope for this working group.

3.4  Sessions

   All the proposals introduce something like a session.  This allows
   the cost of authentication to be amortized over potentially many

3.4.1  Session Keys

   The SBSM proposal's mechanism for session key establishment is
   attractive in explicitly addressing the perfect forward secrecy goal,
   at least for encryption keys.  The same functionality could, however,
   be obtained using the TLSM approach as well.

   Perfect forward secrecy guarantees that compromise of long term
   secret keys does not result in disclosure of past session keys.
   While this is a useful property, it comes at a fairly substantial
   computational cost, and in some cases additional message exchanges.
   There is no clear consensus in the evaluation team about this

3.4.2  Number of Security Levels per Session

   The discussion on the mailing list and in face-to-face meetings led
   the evaluation team to recommend that a session should have a single
   user and security level associated with it.  If an exchange between
   communicating engines would require a different security level or
   would be on behalf of a different user, then another session would be
   needed.  An immediate consequence of this is that implementations
   should be able to maintain some reasonable number of concurrent

Blumenthal, et al.       Expires August 17, 2005               [Page 14]

Internet-Draft          ISMS Proposal Comparison           February 2005

3.4.3  User Caching

   The discussion of user cache lifetimes revealed that different types
   of interactions had different requirements.  For example, ongoing
   polling was different from configuration requests.  Consequently, the
   evaluation team recommends that cache lifetimes not be hard-wired.
   Lifetime could be communicated with the authentication results from
   the authentication server, with a configurable default in the managed
   device for those cases where the authentication server does not
   communicate a user cache entry lifetime.

3.5  Need for Initial Shared Secrets

   Since RADIUS requires a shared secret to be established between the
   RADIUS client and server, it has the same out-of-box problem as USM,
   where one needs to establish the keys for the security administrator,
   who can then create the other users and VACM configurations.  None of
   the proposals address this problem.

3.6  Reuse of Existing Security Protocols

   The evaluation team considers designing and developing a new key
   management protocol for SNMPv3 an unnecessarily complex process and
   generally recommends reuse of existing security protocols where
   possible and appropriate.  In other words, if an existing protocol is
   sufficient for the task at hand, the WG's energies are better spent
   elsewhere in the design of the overall solution for SNMPv3 security.

3.7  Conclusion

   We conclude that neither of the three proposals matches all
   recommendations.  On the other hand, each of them has one or more
   desirable properties that others might draw on to improve their
   original designs.  It is quite tempting to conclude that the
   protocols be "merged" to create a single ISMS protocol.  However,
   that would be ambiguous and would delay the process further.

   The evaluation team concludes that the EUSM architecture would be the
   right direction for the ISMS WG.  However, a number of aspects of the
   EUSM design need moderate to substantial revision.  In the following,
   we first describe the components of the design that we consider most
   attractive, and then list the components that need to be revised and
   suggest components from other proposals as examples as appropriate:

   o  EUSM keeps the current USM model intact.
   o  EUSM integrates well with the AAA architecture.  The evaluation
      team has the following recommendations to improve this

Blumenthal, et al.       Expires August 17, 2005               [Page 15]

Internet-Draft          ISMS Proposal Comparison           February 2005

      *  First, as noted earlier, where possible the design should not
         distinguish between agent and manager, following the SNMPv3
      *  Next, consider the possibility of using the AAA architecture or
         any external authentication infrastructure to establish shared
         secrets a la 802.11i architecture.  Specifically, one of the
         problems with USM is that between n SNMP engines, there might
         O(n^2) pre-shared keys.  The use of a centralized architecture
         will help reduce these keys to O(n), with each engine only
         authenticating to a common entity external to the SNMP world.
         As necessary, any two engines engaging in secure communication
         can establish a common key between them, and generate session
         keys as required by running Bellare-Rogaway's "entity
         authentication and key distribution" protocol [EAKD].  This
         will help reduce the number of interactions between the SNMP

         engines and the AAA server.
      *  The evaluation team recommends that the eventual EUSM
         architecture be generic enough to support Kerberos and other
         authentication architectures.
   o  EUSM is also quite inline with the consensus in the evaluation
      team that, as much as possible the ISMS protocol should be reusing
      existing protocols.
      *  We recommend the EUSM specification clearly identity the work
         in progress protocols that they use, so that the ISMS WG is
         aware of the dependencies on, say PANA, PEAP to name a few.
      *  The other consideration is that the overall architecture once
         complete should be evaluated thoroughly from a security point
         of view.  It is very easy to put together two independently
         secure protocols and open an avenue for a MiTM attack as shown
         by the compound binding attack.
      *  We have several specific concerns (listed below) about some
         protocol choices in EUSM, which should be evaluated and
         justified with analysis and/or WG consensus as applicable.
         +  There is a reference to CBC-DES in Section 3.5.1.  Perhaps
            it is a typo.
         +  EAP-GTC is suggested as the inner EAP method for client
            authentication.  Q: Shouldn't the inner EAP method need to
            be a key generating method for compound binding? Furthermore
            WLAN EAP method recommendations draft specifically excludes
            GTC as the inner EAP method (see [I-D.walker-ieee802-req]).
         +  There should be a discussion on PEAP vs.  other tunneled EAP
            methods, e.g., EAP-TLS, TTLS etc.
   o  As noted in Section 3.1, the evaluation team suggests that EUSM be
      revised to integrate well with RFC 3411 architecture as done by
      the TLSM specification (Please see Section 3.3 - 3.5 and Section 4
      in the TLSM specification [I-D.schoenw-snmp-tlsm]).

Blumenthal, et al.       Expires August 17, 2005               [Page 16]

Internet-Draft          ISMS Proposal Comparison           February 2005

4.  Acknowledgments

   Working group co-chairs Ken Hornstein and Juergen Quittek facilitated
   the meetings of the evaluation team, goading the team to stay focused
   and on schedule.

   The working group charter provided text on requirements and goals.

5.  Security Considerations

   This document compares three different proposals that fix the
   problems associated with USM for SNMPv3 security.  They are all
   architecturally distinct from each other, and have different security
   properties and potential security issues.  The reader is referred to
   the security considerations section within the drafts describing the
   three proposals.

6.  IANA Considerations

   This document requires no actions by IANA.

   All of the proposals evaluated herein would require IANA action if
   adopted by the working group, but in no case was this seen to present
   a significant obstacle.  For example, all the proposals would require
   the allocation of a new value for SnmpSecurityModel [RFC3411].

7.  Informative References

   [EAKD]     Bellare, M. and P. Rogaway, "Entity Authentication and Key
              Distribution", Advances in Cryptology, Crypto '93,
              Lecture Notes in Computer Science 773, 1994.

              Perkins, D. and W. Hardaker, "A Session-Based Security
              Model (SBSM) for version 3 of the Simple Network
              Management Protocol (SNMPv3)",
              Internet-Draft draft-hardaker-snmp-session-sm-03, October

              Lonvick, C., "SSH Protocol Architecture",
              Internet-Draft draft-ietf-secsh-architecture-20, December

              Narayan, K., "External User Security Model (EUSM) for
              version 3 of the Simple Network  Management Protocol


Blumenthal, et al.       Expires August 17, 2005               [Page 17]

Internet-Draft          ISMS Proposal Comparison           February 2005

              Internet-Draft draft-kaushik-snmp-external-usm-01,
              February 2005.

              Rescorla, E., "Datagram Transport Layer Security",
              Internet-Draft draft-rescorla-dtls-02, December 2004.

              Harrington, D. and J. Schoenwaelder, "Transport Layer
              Security Model (TLSM) for the Simple Network Management
              Protocol version 3 (SNMPv3)",
              Internet-Draft draft-schoenw-snmp-tlsm-01, November 2004.

              Stanley, D., Walker, J. and B. Aboba, "EAP Method
              Requirements for Wireless LANs",
              Internet-Draft draft-walker-ieee802-req-04, August 2004.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1492]  Finseth, C., "An Access Control Protocol, Sometimes Called
              TACACS", RFC 1492, July 1993.

   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
              Authentication Service (V5)", RFC 1510, September 1993.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
              Access Protocol (v3)", RFC 2251, December 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

   [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              McCloghrie, K., Rose, M. and S. Waldbusser, "Textual
              Conventions for SMIv2", STD 58, RFC 2579, April 1999.

Blumenthal, et al.       Expires August 17, 2005               [Page 18]

Internet-Draft          ISMS Proposal Comparison           February 2005

   [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2903]  de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D.
              Spence, "Generic AAA Architecture", RFC 2903, August 2000.

   [RFC3410]  Case, J., Mundy, R., Partain, D. and B. Stewart,
              "Introduction and Applicability Statements for
              Internet-Standard Management Framework", RFC 3410,
              December 2002.

   [RFC3411]  Harrington, D., Presuhn, R. and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC3412]  Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
              "Message Processing and Dispatching for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3412, December

   [RFC3413]  Levi, D., Meyer, P. and B. Stewart, "Simple Network
              Management Protocol (SNMP) Applications", STD 62,
              RFC 3413, December 2002.

   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

   [RFC3415]  Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3415, December

   [RFC3416]  Presuhn, R., "Version 2 of the Protocol Operations for the
              Simple Network Management Protocol (SNMP)", STD 62,
              RFC 3416, December 2002.

   [RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3417, December

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62,
              RFC 3418, December 2002.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.

Blumenthal, et al.       Expires August 17, 2005               [Page 19]

Internet-Draft          ISMS Proposal Comparison           February 2005

              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

Authors' Addresses

   Uri Blumenthal
   Intel Corporation

   Phone: +1 973-967-6446
   Email: uri.blumenthal@intel.com

   Lakshminath Dondeti
   Nortel Networks
   600 Technology Park Drive
   Billerica, Massachusetts  01821

   Phone: +1 978-288-6406
   Email: ldondeti@nortel.com

   Randy Presuhn (editor)
   R. Presuhn Consulting
   San Jose, California  95120

   Phone: +1 408-268-2075
   Email: randy_presuhn@mindspring.com

   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, California  94303

   Email: ekr@rtfm.com

Blumenthal, et al.       Expires August 17, 2005               [Page 20]

Internet-Draft          ISMS Proposal Comparison           February 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Blumenthal, et al.       Expires August 17, 2005               [Page 21]