Network Working Group                                      D. Harrington
Internet-Draft                                               Independent
Expires: April 1, 2005                                  J. Schoenwaelder
                                         International University Bremen
                                                            October 2004


     Transport Mapping Security Model (TMSM) for the Simple Network
                 Management Protocol version 3 (SNMPv3)
                     draft-schoenw-snmp-tlsm-01.txt

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.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 1, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes a Transport Mapping Security Model (TMSM) for
   the Simple Network Management Protocol (SNMP) architecture defined in
   RFC3411.  At this stage, this document does not provide a complete
   solution - it rather identifies and discusses some key aspects that
   need discussion and future work.



Harrington & Schoenwaelder    Expires April 1, 2005             [Page 1]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements of a Transport Mapping Security Model . . . . . .  4
     3.1   Security Requirements  . . . . . . . . . . . . . . . . . .  4
     3.2   Architectural Modularity Requirements  . . . . . . . . . .  5
     3.3   Passing messages between Dispatchers . .
. . . . . . . . .  5
     3.4   Security Parameter Passing Requirement . . . . . . . . . .  6
       3.4.1   Using an ASI . . . . . . . . . . . . . . . . . . . . .  6
       3.4.2   Using a cache  . . . . . . . . . . . . . . . . . . . .  6
       3.4.3   Using an encapsulating header  . . . . . . . . . . . .  7
       3.4.4   Using existing fields in a message . . . . . . . . . .  7
     3.5   Access Control Requirements  . . . . . . . . . . . . . . .  8
       3.5.1   Architectural securityName Binding Requirement . . . .  8
   4.  Fields in the SNMPv3 message . . . . . . . . . . . . . . . . .  8
     4.1   msgVersion . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2   msgGlobalData  . . . . . . . . . . . . . . . . . . . . . .  9
     4.3   securityLevel and msgFlags . . . . . . . . . . . . . . . .  9
     4.4   The tmStateReference for Passing Security Parameters . . . 11
     4.5   securityStateReference Cached Security Data  . . . . . . . 11
       4.5.1   Prepare an Outgoing SNMP Message . . . . . . . . . . . 12
       4.5.2   Prepare Data Elements from an Incoming SNMP Message  . 12
     4.6   Notifications  . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Transport Mapping Security Model Samples . . . . . . . . . . . 13
     5.1   TLS/TCP Transport Mapping Security Model . . . . . . . . . 13
       5.1.1   tmStateReference for TLS . . . . . . . . . . . . . . . 13
       5.1.2   MP portion for TLS TM-Security Model . . . . . . . . . 14
       5.1.3   MIB Module for TLS Security  . . . . . . . . . . . . . 14
     5.2   DTLS/UDP  Transport Mapping Security Model . . . . . . . . 14
       5.2.1   tmStateReference for DTLS  . . . . . . . . . . . . . . 15
     5.3   SASL Transport Mapping Security Model  . . . . . . . . . . 16
       5.3.1   tmStateReference for SASL  DIGEST-MD5  . . . . . . . . 16
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 17
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 18
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
   A.  Message security versus session security . . . . . . . . . . . 19
     A.1   msgFlags versus actual security  . . . . . . . . . . . . . 19
     A.2   Message security versus session security . . . . . . . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 21









Harrington & Schoenwaelder    Expires April 1, 2005             [Page 2]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


1.  Introduction

   There are multiple ways to secure one's home or business, but they
   largely boil down to a continuum of alternatives.  Let's consider
   three general approaches.  In the first approach, an individual/
   company could buy a gun, learn to use it, and sit on your front porch
   waiting for intruders.  In the second approach, one could hire an
   employee with a gun, schedule the employee, position the employee to
   guard what you want protected, hire a second guard to cover if the
   first gets sick, and so on.  In the third approach, you could hire a
   security company, tell them what you want protected, and they could
   hire employees, train them, buy the guns, position the guards,
   schedule the guards, send a replacement when a guard cannot make it,
   etc., thus providing the security you want, with no significant
   effort on your part other than identifying requirements and verifying
   the quality of the service being provided.

   The User-based Security Model (USM) as defined in [RFC3414] largely
   uses the first approach - it provides its own security.  It utilizes
   existing mechanisms (MD5=the gun), but provides all the coordination.
   USM provides for the authentication of a principal, message
   encryption, data integrity checking, timeliness checking, etc.

   USM was designed to be independent of other existing security
   infrastructures.  USM therefore requires a separate user and key
   management infrastructure.  Operators have reported that deploying
   another user and key management infrastructure in order to use SNMPv3
   is a reason for not  deploying SNMPv3 at this point in time.  It is
   possible but difficult to define external mechanisms that handle the
   distribution of keys for use by the USM approach.

   A solution based on the second approach might use a USM-compliant
   architecture, but replace the authentication mechanism with an
   external mechanism, such as RADIUS, to provide the authentication
   service.  It might be possible to utilize an external protocol to
   encrypt a message, to check timeliness, to check data integrity, etc.
   It is difficult to cobble together a number of subcontracted services
   and coordinate them however, because it is difficult to build solid
   security bindings between the various services, and potential for
   gaps in the security is significant.

   A solution based on the third approach might utilize one or more
   lower-layer security mechanisms to provide the message-oriented
   security services required.  These would include authentication of
   the sender, encryption, timeliness checking, and data integrity
   checking.  There are a number of IETF standards available or in
   development to address these problems at lower layers, frequently at
   the transport layer.  A solution based on this approach might also



Harrington & Schoenwaelder    Expires April 1, 2005             [Page 3]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   utilize a "transport" that is actually another application operating
   at the application layer, such as SSH [SSHauth]

   This document proposes a Transport Mapping Security Model (TMSM), as
   an extension of the SNMPv3 architecture, that would allow security to
   be provided an external protocol connected to the SNMP engine through
   an SNMP transport-mapping.  Such a TMSM would then enable the use of
   existing security mechanisms such as (TLS) [RFC2246], Kerberos
   [RFC1510] or SASL [RFC2222] within the SNMPv3 architecture.

   As pointed out in the EUSM proposal [EUSM], it is desirable to use
   mechanisms that could "unify the approach for administrative security
   for SNMPv3 and CLI" and other management interfaces.  The use of
   security services provided by lower layers or other applications is
   the approach commonly used for the CLI, and is the approach being
   proposed for NETCONF

   This document provides the motivation for leveraging transport layer
   security mechanisms for secure SNMP communication, identifies some
   key issues and provides some proposals for design choices that may be
   made to provide a workable solution that meets operational
   requirements and fits into the SNMP architecture defined in [RFC3411]

2.  Motivation

   There are a number of Internet security protocols and mechanisms that
   are in wide spread use.  Many of them try to provide a generic
   infrastructure to be used by many different application layer
   protocols.  The motivation  behind TMSM is to leverage these
   protocols where it seems useful.

   There are a number of challenges to be addressed to map the security
   provided by a secure transport into the SNMP architecture so that
   SNMP continues to work without any surprises.  These are discussed in
   detail below.

3.  Requirements of a Transport Mapping Security Model

3.1  Security Requirements

   Transport mapping security protocols SHOULD ideally provide the
   protection against the following message-oriented threats [RFC3411]:

   1.  modification of information
   2.  masquerade
   3.  message stream modification
   4.  disclosure




Harrington & Schoenwaelder    Expires April 1, 2005             [Page 4]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   According to [RFC3411], it i
s not required to protect against denial
   of service or traffic analysis.

3.2  Architectural Modularity Requirements

   [RFC3411] section 3 describes a modular architecture to allow the
   evolution of the SNMP protocol standards over time.  This
   architecture includes a Security Subsystem which is responsible for
   realizing security services.

   Transport mapping security is by its very nature a security layer
   which is plugged in between the transport layer and the dispatcher.
   Conceptually, transport mapping security models will be called from
   within the Transport Mapping portion of an SNMP engine, or will be
   positioned between the transport mapping subsystem and the
   dispatcher.

   The design of a transport mapping security model must abide the goals
   of the RFC3411 architecture, section 1.  To that end, this transport
   mapping security model proposal focuses on a modular subsystem that
   can be advanced through the standards process independently of other
   proposals, and independent of other subsystems as much as possible.

   This subsystem is designed as an architectural extension that permits
   different transport mapping security protocols to be "plugged into"
   this subsystem, to support supplemental transport mapping security
   models in addition to those described here.

   IETF standards typically require one mandatory-to-implement solution,
   with the capability of adding new security mechanisms in the future.
   Any transport mapping security model should define one
   minimum-compliance mechanism, preferably one which is already widely
   deployed within the transport layer security protocol used.

   This architectural extension is illustrated by the following diagram,
   which is a modified version of the diagram taken from the SNMP
   architecture document.

   TODO: Insert drawing here...


3.3  Passing messages between Dispatchers

   Typically, with a TMSM model, the transport mapping will establish an
   encrypted tunnel between the transport mappings of two SNMP engines,
   without passing anything to the SNMP dispatcher.  One transport
   mapping  security model instance encrypts all messages, and the other
   transport mapping security model instance decrypts the messages.



Harrington & Schoenwaelder    Expires April 1, 2005             [Page 5]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   After the transport layer tunnel is established, then SNMP messages
   can conceptually be sent through the tunnel from one SNMP engine
   dispatcher to another SNMP engine dispatcher.  SNMP messages are
   passed unencrypted from the source dispatcher to its own TMSM, and
   presented unencrypted to the destination SNMP dispatcher.

   Once the tunnel is established, multiple SNMP messages may be able to
   be passed through the same tunnel.

3.4  Security Parameter Passing Requirement

   [RFC3411] section 4 describes primitives to describe the abstract
   service interfaces  used to conceptually pass information between the
   various subsystems, models and applications within the architecture.
   A Transport mapping Security Model must pass information between
   subsystems as well.

   The RFC3411 architecture has no ASI parameters for passing security
   information between the transport mapping and the dispatcher, and
   between the dispatcher and the message processing model.  Since the
   TM portion of the security model and the MP portion of the security
   model are co-resident within an implementation, it is assumed there
   is a trust relationship that exists within the implementation.  There
   are four approaches that could be used for passing information
   between the TM portion of the securitymodel and the MP portion of the
   security model :
      we could define an ASI to supplement the existing ASIs, or
      the TMSM could pass the information in an implementation-specific
      cache, or
      the TMSM could add a header to encapsulate the SNMP message, or
      the TMSM could utilize fields already defined in the existing
      SNMPv3 message.

3.4.1  Using an ASI

   RFC3411 discusses the purpose, and an explicit non-purpose, of the
   ASI approach: "This modularity of specification is not meant to be
   interpreted as imposing any specific requirements on implementation."
   An ASI is not an API, and following a defined ASI is not required for
   interoperability, so implementors are really free to use any method
   they choose.  However, defining an ASI has the advantage of being
   consistent with existing RFC3411/3412 practice.

3.4.2  Using a cache

   A cache mechanism could be used, into which the TM portion of the
   security model puts information about the security applied to an
   incoming message, and an MP portion of the security model extracts



Harrington & Schoenwaelder    Expires April 1, 2005             [Page 6]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   that information from the cache.  The cache is not passed via an
   explicit ASI.  Given that there may be multiple TM-security caches, a
   cache ID probably needs to be passed in the message in the ASI so the
   MP portion of the security model knows which cache to consult.  This
   approach would be consistent with the securityStateReference cache
   already being passed around in the ASI.

   The cache could be thought of as an additional parameter in the ASI.
   The ASI would not need to be changed since the SNMPv3 WG expected
   that additional parameters could be passed for value-add features of
   specific implementations.

3.4.3  Using an encapsulating header

   A header could encapsulate the SNMP message to pass necessary
   information from the TM portion of the security model to the
   dispatcher and then to the MP portion of the security model.  The
   message header would be included in the wholeMessage ASI parameter,
   and would be removed by a corresponding messaging model.  This would
   imply a new messaging model would need to be specified as well.  The
   other approaches may be able to use the standard SNMPv3 messaging
   model, with a new MP-security model.

3.4.4  Using existing fields in a message

   [RFC3412] describes the SNMPv3 message, which contains fields to pass
   security related parameters.  The TMSM could use these fields in an
   SNMPv3 message, or comparable fields in other message formats to pass
   information between transport mapping security models in different
   SNMP engines, and to pass information between a TM security model and
   the corresponding MP security model.

   It is importnat to understand that SNMP messages are ASN.1 encoded,
   and the SNMP architecture places no constraints on how the ASN.1 gets
   decoded - it might be decoded in one massive decode, or individual
   portions of the message, such as individual varbinds, may be decoded
   only as needed.  This is an implementation decision.

   If the fields in an incoming SNMPv3 message are changed by the TM
   portion before passing it to the MP portion, then the TM portion will
   need to encode its parameters in ASN.1 or the message model would
   need to be modified to permit non-encoded data to be added to the
   message in a  manner that would not impact the existing ASN.1
   encoding/decoding of the message.  In addition, the MP portion may
   not be able to perform a transport-independent message integrity
   check, and transport-independent encryption may not be able to be
   performed by the MP portion of the model.  While it may be desirable
   for most TMSM models to perform those services through the TM portion



Harrington & Schoenwaelder    Expires April 1, 2005             [Page 7]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   of the model, assuming the use of a cache or an encapsulating header
   would not impose such constraints on future models.

   This document will describe a cache approac
h, but an encapsulating
   header or other mechanisms could also be used if preferred for
   specific TM security models.

3.5  Access Control Requirements

3.5.1  Architectural securityName Binding Requirement

   For SNMP access control to function properly, the security mechanism
   must establish a securityName, which is the security model
   independent identifier for a principal, a security model identifier,
   and a securityLevel.  The SNMPv3 message processing architecture
   subsystem relies on a message model based security model, such as
   USM, to play an  role in security that goes beyond protecting the
   message - it ties various security models for the same principal to a
   security-model independent securityName which can be used for
   subsequent processing, such as for access control.

   The TMSM assumes two portions to a security model, one tied to the
   transport mapping and another tied to the message processing model.
   and will be referred to here as a TM-portion and an MP-portion of the
   security model.  Depending on the specific design of the security
   model, different features might be provided by the TM portion or by
   the MP portion.  For example, the binding of a mechanism-specific
   authenticated identity to a securityName might be done by the TM
   portion or by the MP portion.

   The SNMP architecture distinguishes between messages with no
   authentication and no privacy (noAuthNoPriv), authentication without
   privacy (authNoPriv) and authentication with privacy (authPriv).
   Hence, the authentication of a transport layer identity plays an
   important role and must be considered by any transport layer security
   mechanism used.  However, it is also possible that a second level of
   authentication, one provided by a AAA server, for example, may be
   used to provide the authentication identity which is bound to the
   securityName, if the type of authentication provided by the transport
   layer (e.g.  host-based or anonymous) is considered adequate to
   secure and/or encrypt the message, but inadequate to provide the
   desired granularity of access control  (e.g.  user-based).

4.  Fields in the SNMPv3 message

4.1  msgVersion

   For proposals that reuse the SNMPv3 message format, this field should



Harrington & Schoenwaelder    Expires April 1, 2005             [Page 8]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   contain the value 3.

4.2  msgGlobalData

   msgID and msgMaxSize are used identically for the TMSM models as for
   the USM model.

   msgSecurityModel should be set to a value from the SnmpSecurityModel
   enumeration [RFC3410] to identify the specific TMSM model.

   msgSecurityParameters is used identically for the TMSM models as for
   the USM model.

   msgFlags have the same values for the TMSM models as for the USM
   model.  "The authFlag and privFlag fields indicate the securityLevel
   that was applied to the message before it was sent on the wire."

4.3  securityLevel and msgFlags

   For an outgoing message, msgFlags is the requested security for the
   message; if a TMSM cannot provide the requested securityLevel, the
   model MUST describe a standard behavior that is followed for that
   situation.  If the TMSM cannot provide at least the requested level
   of security, the TMSM MUST discard the request and SHOULD notify the
   message processing model that the request failed.  [dbh: how is yet
   to be determined, and may be model-specific or
   implementation-specific.]

   For an outgoing message, if the TMSM is  able to provide stronger
   than requested security, that may be acceptable.  The transport layer
   protocol would need to indicate to the receiver what security has
   been applied to the actual message.  To avoid the need to mess with
   the ASN.1 encoding, the SNMPv3 message carries the requested
   msgFlags, not the actual securityLevel applied to the message.  If a
   message format other than SNMPv3 is used, then the new message may
   carry the more accurate securityLevel in the SNMP message.

   For an incoming message, the receiving TMSM knows what must be done
   to process the message based on the transport layer mechanisms.  If
   the underlying transport security mechanisms for the receiver cannot
   provide the matching securityLevel, then the message should follow
   the standard  behaviors for the transport security mechanism, or be
   discarded silently.

   Part of the responsibility of the TMSM is to ensure that the actual
   security provided by the underlying transport layer security
   mechanisms is configured to meet or exceed the securityLevel required
   by the msgFlags in the SNMP message.  When the MP portion of the



Harrington & Schoenwaelder    Expires April 1, 2005             [Page 9]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   security model processes the incoming message, it should compare the
   msgFlags field to the securityLevel actually provided for the message
   by the transport layer security.  If they differ, the MP portion of
   the security model should determine whether the changed securityLevel
   is acceptable.  If not, it should discard the message.  Depending on
   the model, the MP portion may issue a reportPDU with the XXXXXXX
   model-specific counter.

   Questions about msgFlags:

      Is the securityLevel looked at before the security model gets to
      it.? No.  the security model has two parts - the TM portion and
      the MP portion.  The securityLevel is looked at by the TM portion
      before it gets to the MP piece, but both are parts of the same
      security model.
      Would it be legal for the security model to ignore the incoming
      flags and change them before passing them back up? If it changed
      them, it wouldn't necessarily be ignoring them.  The TM portion
      should pass both an actual securityLevel applied to the message,
      and the msgFlags in the SNMP message to the MP piece for
      consideration related to access control..  The msgFlags parameter
      in the SNMP message is never changed when processing an incoming
      message.
      Would it be legal for the security model to ignore the outgoing
      flags and change them before passing them out? no; because the two
      portions are parts of the same security model, either the MP piece
      should recognize that a securityLevel cannot be met or exceeded,
      and reject the message during the message-build phase, or the TM
      piece should determine if it is possible to honor the request.  It
      is possible to apply an increased securityLevel for an outgoing
      request, but the procedure to do so must be spelled out clearly in
      the model design.
      The security model would need to (MUST) check the incoming
      security level flags to make sure they matched the TLS/whatever
      session setup and if not drop the message.  Yes, mostly.
      Depending on the model, either the TM portion or the MP portion
      MUST verify that the actual processing met or exceeded the
      securityLevel requested by the msgFlags and that it is acceptable
      to the specific-model processing (or operator configuration) for
      this different securityLevel to be applied to the message.  This
      is also true (especially) for outgoing messages.
      You might legally be able to have a authNoPriv message that is
      actually encrypted via the transport (but not the other way around
      of course).  Yes, a TMSM could define that as the behavior (or
      permit an operator to specify that is acceptable behavior) when a
      requested securityLevel cannot be provided, but a stronger
      securityLevel can be provided.




Harrington & Schoenwaelder    Expires April 1, 2005            [Page 10]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   See the Appendix A appendix for further discussion of the msgFlags
   field ve
rsus the actual securityLevel provided.  [dbh: it may be a
   good thing to merge the Question and Answer with the appendix, either
   here or there.]

4.4  The tmStateReference for Passing Security Parameters

   A tmStateReference is used to pass data between the TM portion and
   the MP portion of the security model, similar to the
   securityStateReference described in RFC3412.  This can be envisioned
   as being appended to the ASIs between the TM and the MP or as being
   passed in an encapsulating header.

   The TM portion of the security model may provide only some aspects of
   security, and leave some aspects to the MP portion of the model.
   tmStateReference should be used to pass any parameters, in a model-
   and mechanism-specific format, that will be needed to coordinate the
   activities of the TM and MP portions of the model, and the parameters
   subsequently passed in  securityStateReference .  For example, the TM
   portion may provide privacy and data integrity and authentication and
   authorization policy retrievals, or some subset of these features,
   depending on the features available in the transport mechanisms.  A
   field in tmStateReference should identify which services were
   provided for each received message by the TM portion,  the
   securityLevel applied to the received message, the model-specific
   security identity, the session identifier for session based transport
   security, and so on.

4.5  securityStateReference Cached Security Data

   From RFC3411: "For each message received, the Security Model caches
   the state information such that a Response message can be generated
   using the same security information, even if the Local Configuration
   Datastore is altered between the time of the incoming request and the
   outgoing response.

   A Message Processing Model has the responsibility for explicitly
   releasing the cached data if such data is no longer needed.  To
   enable this, an abstract securityStateReference data element is
   passed from the Security Model to the Message Processing Model.  The
   cached security data may be implicitly released via the generation of
   a response, or explicitly released by            using the stateRelease
   primitive, as described in section 4.5.1."

   To differentiate what information needs to be provided to the MP
   portion by the TM portion, and vice-versa, this document will
   differentiate the tmStateReference from the securityStateReference.
   An implementation MAY use one cache and one reference to serve both



Harrington & Schoenwaelder    Expires April 1, 2005            [Page 11]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   functions, but an implementor must be aware of the cache-release
   issues to prevent the cache from being released before the TM portion
   has had an opportunity to extract the information it needs.

4.5.1  Prepare an Outgoing SNMP Message

   According to RFC3412, section 7.1,  the SNMPv3 message processing
   model calls the MP portion of the TM security model using the
   generateResponseMsg() or generateRequestMsg().  The MP portion of the
   model may need to put information into the tmStateReference cache for
   use by the TM portion of the model, such as:
      tmSecurityStateReference - the unique identifier for the cached
      information
      tmTransportDomain
      tmTransportAddress
      tmSecurityModel - an indicator of which mechanisms to use
      tmSecurityName - a model-specific identifier of the security
      principal
      tmSecurityLevel - an indicator of which security services are
      requested
   and may contain additional information such as
      tmSessionID
      tmSessionKey
      tmSessionMsgID

4.5.2  Prepare Data Elements from an Incoming SNMP Message

   For an incoming message, the TM portion of a model will need to put
   information from the transport mechanisms used into the
   tmStateReference so the MP portion of the model can extract the
   information and add it conceptually to the securityStateReference.

   The tmStateReference cache will likely contain at least the following
   information:
      tmStateReference - a unique identifier for the cached information
      tmSecurityStateReference - the unique identifier for the cached
      information
      tmTransportDomain
      tmTransportAddress
      tmSecurityModel - an indicator of which mechanisms to use
      tmSecurityName - a model-specific identifier of the security
      principal
      tmSecurityLevel - an indicator of which security services are
      requested
      tmAuthProtocol
      tmPrivProtocol
   and may contain additional information such as




Harrington & Schoenwaelder    Expires April 1, 2005            [Page 12]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


      tmSessionID
      tmSessionKey
      tmSessionMsgID

4.6  Notifications

   For notifications, if the cache has been released and then session
   closed, then the MP portion of the security model will request the TM
   portion of the security model to establish a session, populate the
   cache, and pass the securityStateReference to the MP portion of the
   security model.

   TODO: We need to determine what state needs to be saved here.

5.  Transport Mapping Security Model Samples

5.1  TLS/TCP Transport Mapping Security Model

   SNMP supports multiple transports.  The preferred transport for SNMP
   over IP is UDP [RFC3417].  An experimental transport for SNMP over
   TCP is defined in [RFC3430].

   TLS/TCP will create an association between the TMSM of one SNMP
   entity and the TMSM of another SNMP entity.  The created "tunnel" may
   provide encryption and data integrity.  Both encryption and data
   integrity are optional features in TLS.  The TLS TM portion of the
   security model MUST provide authentication if auth is requested in
   the securityLevel of the SNMP message request (RFC3412 4.1.1).  The
   TLS TM-security model MUST specify that the messages be encrypted if
   priv is requested in the securityLevel parameter of the SNMP message
   request (RFC3412 4.1.1).

   The TLS TM-security model SHOULD use the TLS Handshake Protocol with
   mutual authentication.

5.1.1  tmStateReference for TLS

   Upon establishment of a TLS session, the TM-security model will cache
   the state information.  A tmStateReference that is unique within the
   SNMP entity will be stored in the cache, and passed to the
   corresponding MP portion of the security model, to enable lookup.
   The MP security model will pass the securityStateReference to the
   Message Processing Model for memory management.

   The tmStateReference cache:
      tmStateReference
      tmSecurityStateReference




Harrington & Schoenwaelder    Expires April 1, 2005            [Page 13]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


      tmTransportDomain = TCP/IPv4
      tmTransportAddress = x.x.x.x:y
      tmSecurityModel - TLS TMSM
      tmSecurityName = "dbharrington"
      tmSecurityLevel = "authPriv"
      tmAuthProtocol = Handshake MD5
      tmPrivProtocol = Handshake DES
      tmSessionID = Handshake session identifier
      tmSessionKey = Handshake peer certificate
      tmSessionMasterSecret = master secret
      tmSessionParameters = compression method, cipher spec,
      is-resumable

5.1.2  MP portion for TLS TM-Security Model

      messageProcessingModel   = SNMPv3
      securityModel            = TLS TMSM
      securityName             = tmSecurityName
      securityLevel              = msgSecurityLevel

5.1.3  MIB Module for TLS Security

   Each security model should use its own MIB module, rather than
   utilizing the USM MIB, to eliminate dependencies on a model that
   could be replaced some day.  See RFC3411 section 4.1.1.

   The TLS MIB module needs to provide the mapping from model-specific
   identity to a model independent securityName.

   TO
DO: Module needs to be worked out once things become stable...

5.2  DTLS/UDP  Transport Mapping Security Model

   DTLS has been proposed as a UDP-based TLS.  Transport Layer Security
   (TLS) [RFC2246] traditionally requires a connection-oriented
   transport and is usually used over TCP.  Datagram Transport Layer
   Security (DTLS) [DTLS] provides security services equivalent to TLS
   for connection-less transports such as UDP.

   DTLS provides all the security services needed from an SNMP
   architectural point of view.  Although it is possible to derive a
   securityName from the public key certificates (e.g.  the subject
   field), this approach requires to install certificates on agents and
   as well as managers, leading to a certificate management problem
   which again does not integrate well with established AAA systems.

   Another option is to run an authentication exchange which is
   integrated with TLS, such as Secure Remote Password with TLS



Harrington & Schoenwaelder    Expires April 1, 2005            [Page 14]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   [SRP-TLS].  A similar option would be to use Kerberos authentication
   with TLS as defined in [RFC2712].

   It is important to stress that the authentication exchange must be
   integrated into the TLS mechanism to prevent man-in-the-middle
   attacks.  While SASL [RFC2222] is often used on top of a TLS
   encrypted channel to authenticate users, this choice seems to be
   problematic until the mechanism to cryptographically bind SASL into
   the TLS mechanism has been defined.

   DTLS will create an association between the TMSM of one SNMP entity
   and the TMSM of another SNMP entity.  The created "tunnel" may
   provide encryption and data integrity.  Both encryption and data
   integrity are optional features in DTLS.  The DTLS TM-security model
   MUST provide authentication if auth is requested in the securityLevel
   of the SNMP message request (RFC3412 4.1.1).  The TLS TM-security
   model MUST specify that the messages be encrypted if priv is
   requested in the securityLevel parameter of the SNMP message request
   (RFC3412 4.1.1).

   The DTLS TM-security model SHOULD use the TLS Handshake Protocol with
   mutual authentication.

5.2.1  tmStateReference for DTLS

   Upon establishment of a DTLS session, the TM-security model will
   cache the state information.  A tmStateReference that is unique
   within the SNMP entity will be stored in the cache, and passed to the
   corresponding MP portion of the security model, to enable lookup.
   The MP security model will pass the securityStateReference to the
   Message Processing Model for memory management.

   The tmStateReference cache:
      tmStateReference
      tmSecurityStateReference
      tmTransportDomain = UDP/IPv4
      tmTransportAddress = x.x.x.x:y
      tmSecurityModel - DTLS TMSM
      tmSecurityName = "dbharrington"
      tmSecurityLevel = "authPriv"
      tmAuthProtocol = Handshake MD5
      tmPrivProtocol = Handshake DES
      tmSessionID = Handshake session identifier
      tmSessionKey = Handshake peer certificate
      tmSessionMasterSecret = master secret
      tmSessionParameters = compression method, cipher spec,
      is-resumable




Harrington & Schoenwaelder    Expires April 1, 2005            [Page 15]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


      tmSessionSequence = epoch, sequence

   TODO:
      Need to discuss to what extent DTLS is a reasonable choice for
      SNMP interactions.
      What is the status of the work to cryptographically bind SASL to
      DTLS?
      More details need to be worked out...

5.3  SASL Transport Mapping Security Model

   The Simple Authentication and Security Layer (SASL) [RFC2222]
   provides a hook for authentication and security mechanisms to be used
   in application protocols.  SASL supports a number of authentication
   and security mechanisms, among them Kerberos via the GSSAPI
   mechanism.

   This sample will use DIGEST-MD5 because it supports authentication,
   integrity checking, and confidentiality.

   DIGEST-MD5 supports auth, auth with integrity, and auth with
   confidentiality.  Since SNMPv3 assumes integrity checking is part of
   authentication, if msgFlags is set to authNoPriv, the qop-value
   should be set to auth-int; if msgFlags is authPriv, then qop-value
   should be auth-conf.

   Realm is optional, but can be utilized by the securityModel if
   desired.  SNMP does not use this value, but a TMSM could map the
   realm into SNMP processing in various ways.  For example, realm and
   username could be concatenated to be the securityName value, e.g.
   helpdesk::username", or the realm could be used to specify a
   groupname to use in the VACM access control.  This would be similar
   to the EUSM's approach to having the securityName-to-group mapping
   done by the external AAA server.

5.3.1  tmStateReference for SASL  DIGEST-MD5

   The tmStateReference cache:
      tmStateReference
      tmSecurityStateReference
      tmTransportDomain = TCP/IPv4
      tmTransportAddress = x.x.x.x:y
      tmSecurityModel - SASL TMSM
      tmSecurityName = username
      tmSecurityLevel = [auth-conf]
      tmAuthProtocol = md5-sess
      tmPrivProtocol =  3des




Harrington & Schoenwaelder    Expires April 1, 2005            [Page 16]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


      tmServicesProvided =
         mutual authentication,
         reauthentication,
         integrity,
         encryption
      tmParameters = "realm=helpdesk, serv-type=SNMP

6.  Acknowledgments

   The authors would like to thank Ira McDonald, Ken Hornstein, and
   Nagendra Modadugu for their comments and suggestions.

7.  References

7.1  Normative References

   [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 SNMP", STD 62, RFC
              3412, 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.

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

   [RFC3430]  Schoenwaelder, J., "Simple Network Management Protocol
              (SNMP) over Transmission Control Protocol (TCP) Transport
              Mapping", RFC 3430, December 2002.

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

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

   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
              (SASL)", STD 62, RFC RFC2222, October 1997.

   [DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", ID draft-rescorla-dtls-01.txt, July 2004.



Harrington & Schoenwaelder    Expires April 1, 2005            [Page 17]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


7.2  Informative References

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

   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
              Suites to Transport Layer Security (TLS)", RFC 2712,
              October 1999.

   [SRP-TLS]  Taylor, D., Wu, T., Mavroyanopoulos, M. and T. Perrin,

     "Using SRP for TLS Authentication", ID
              draft-ietf-tls-srp-08.txt, August 2004.

   [EUSM]     Narayan, D., McCloghrie, K., Salowey, J. and C. Elliot,
              "External USM for SNMPv3", ID
              draft-kaushik-snmp-external-usm-00.txt, July 2004.

   [NETCONF]  Enns, R., "NETCONF Configuration Protocol", ID
              draft-ietf-netconf-prot-04.txt, October 2004.

   [SSHauth]  Lonvick, C., "SSH Authentication Protocol", ID
              draft-ietf-secsh-userauth-21.txt, June 2004.


Authors' Addresses

   David Harrington
   Independent
   Harding Rd
   Portsmouth NH
   USA

   Phone: +1 603 436 8634
   EMail: dbharrington@comcast.net


   Juergen Schoenwaelder
   International University Bremen
   Campus Ring 1
   28725 Bremen
   Germany

   Phone: +49 421 200-3587
   EMail: j.schoenwaelder@iu-bremen.de





Harrington & Schoenwaelder    Expires April 1, 2005            [Page 18]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


Appendix A.  Message security versus session security

A.1  msgFlags versus actual security

   Using IPSEC, SSH, or SSL/TLS to provide security services "below" the
   SNMP message, the use of securityName and securityLevel will differ
   from the USM/VACM approach to SNMP access control.  VACM uses the
   "securityName" and the "securityLevel" to determine if access is
   allowed.  With the SNMPv3 message and USM security model, both
   securityLevel and securityName are contained in every SNMPv3 message.

   Any proposal for a security model using IPSEC, SSH, or SSL/TLS needs
   to specify how this info is made available to the SNMPv3 message
   processing, and how it is used.

   One specific case to consider is the relationship between the
   msgFlags of an SNMPv3 message, and the actual services provided by
   the lower layer security.  For example, if a session is set up with
   encryption, is the priv bit always (or never) set in the msgFlags
   field, and is the PDU never (or always) encrypted? Do msgFlags have
   to match the security services provided by the lower layer, or are
   the msgFlags ignored and the values from the lower layer used?

A.2  Message security versus session security

   For SBSM, and for many TMSM models, securityName is specified during
   session setup, and associated with the session identifier.  Is it
   possible for the request (and notification) originator to specify per
   message auth and encryption services, or are they are "fixed" by the
   transport/session model?

   If a session is created as 'authPriv', then keys for encryption would
   still be negotiated once at the beginning of the session.  But if a
   message is presented to the session with a security level of
   authNoPriv, then that message could simply be authenticated and not
   encrypted.  Wouldn't that also have some security benefit, in that it
   reduces the encrypted data available to an attacker gathering packets
   to try and discover the encryption keys?

   Agents are often resource-constrained.  Adding sessions increases the
   need for resources, we shouldn't require two sessions when one can
   suffice.  2 bytes per session structure and a compare or two is much
   less of a resource burden on an agent than two separate sessions.

   It's not just about CPU power of the device but the percentage of CPU
   cycles that are spent on network management.  There isn't much value
   in using encryption for a performance management system polling PEs
   for performance data on thousands of interfaces every ten minutes,it



Harrington & Schoenwaelder    Expires April 1, 2005            [Page 19]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


   just adds significant overhead to processing of the packet.  Using an
   encrypted TLS channel for everything may not work for use cases in
   performance management wherein we collect massive amounts of non
   sensitive data at periodic intervals.  Each SNMP "session" would have
   to negotiate two separate protection channels (authPriv and
   authNoPriv) and for every packet the SNMP engine will use the
   appropriate channel based on the desired securityLevel.

   If the underlying transport layer security was configurable on a
   per-message basis, a TMSM could have a MIB module with configurable
   maxSecurityLevel and a minSecurityLevel objects to identify the range
   of possible levels, and not all messages sent via that session are of
   the same level.  A session's maxSecurityLevel would identify the
   maximum security it could provide, and a session created with a
   minSecurityLevel of authPriv would reject an attempt to send an
   authNoPriv message.



































Harrington & Schoenwaelder    Expires April 1, 2005            [Page 20]


Internet-Draft    SNMPv3 Transport Mapping Security Model   October 2004


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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


Acknowledgment

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




Harrington & Schoenwaelder    Expires April 1, 2005            [Page 21]