<pre>Network Working Group                                      D. Harrington
Request for Comments: 5591                     Huawei Technologies (USA)
Category: Standards Track                                    W. Hardaker
                                               Cobham Analytic Solutions
                                                               June 2009


                    <span class="h1">Transport Security Model for the</span>
               <span class="h1">Simple Network Management Protocol (SNMP)</span>

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.











<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


Abstract

   This memo describes a Transport Security Model for the Simple Network
   Management Protocol (SNMP).

   This memo also defines a portion of the Management Information Base
   (MIB) for monitoring and managing the Transport Security Model for
   SNMP.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. The Internet-Standard Management Framework .................<a href="#page-3">3</a>
      <a href="#section-1.2">1.2</a>. Conventions ................................................<a href="#page-3">3</a>
      <a href="#section-1.3">1.3</a>. Modularity .................................................<a href="#page-4">4</a>
      <a href="#section-1.4">1.4</a>. Motivation .................................................<a href="#page-5">5</a>
      <a href="#section-1.5">1.5</a>. Constraints ................................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. How the Transport Security Model Fits in the Architecture .......<a href="#page-6">6</a>
      <a href="#section-2.1">2.1</a>. Security Capabilities of this Model ........................<a href="#page-6">6</a>
           <a href="#section-2.1.1">2.1.1</a>. Threats .............................................<a href="#page-6">6</a>
           <a href="#section-2.1.2">2.1.2</a>. Security Levels .....................................<a href="#page-7">7</a>
      <a href="#section-2.2">2.2</a>. Transport Sessions .........................................<a href="#page-7">7</a>
      <a href="#section-2.3">2.3</a>. Coexistence ................................................<a href="#page-7">7</a>
           <a href="#section-2.3.1">2.3.1</a>. Coexistence with Message Processing Models ..........<a href="#page-7">7</a>
           <a href="#section-2.3.2">2.3.2</a>. Coexistence with Other Security Models ..............<a href="#page-8">8</a>
           <a href="#section-2.3.3">2.3.3</a>. Coexistence with Transport Models ...................<a href="#page-8">8</a>
   <a href="#section-3">3</a>. Cached Information and References ...............................<a href="#page-8">8</a>
      <a href="#section-3.1">3.1</a>. Transport Security Model Cached Information ................<a href="#page-9">9</a>
           <a href="#section-3.1.1">3.1.1</a>. securityStateReference ..............................<a href="#page-9">9</a>
           <a href="#section-3.1.2">3.1.2</a>. tmStateReference ....................................<a href="#page-9">9</a>
           <a href="#section-3.1.3">3.1.3</a>. Prefixes and securityNames ..........................<a href="#page-9">9</a>
   <a href="#section-4">4</a>. Processing an Outgoing Message .................................<a href="#page-10">10</a>
      <a href="#section-4.1">4.1</a>. Security Processing for an Outgoing Message ...............<a href="#page-10">10</a>
      <a href="#section-4.2">4.2</a>. Elements of Procedure for Outgoing Messages ...............<a href="#page-11">11</a>
   <a href="#section-5">5</a>. Processing an Incoming SNMP Message ............................<a href="#page-12">12</a>
      <a href="#section-5.1">5.1</a>. Security Processing for an Incoming Message ...............<a href="#page-12">12</a>
      <a href="#section-5.2">5.2</a>. Elements of Procedure for Incoming Messages ...............<a href="#page-13">13</a>
   <a href="#section-6">6</a>. MIB Module Overview ............................................<a href="#page-14">14</a>
      <a href="#section-6.1">6.1</a>. Structure of the MIB Module ...............................<a href="#page-14">14</a>
           <a href="#section-6.1.1">6.1.1</a>. The snmpTsmStats Subtree ...........................<a href="#page-14">14</a>
           <a href="#section-6.1.2">6.1.2</a>. The snmpTsmConfiguration Subtree ...................<a href="#page-14">14</a>
      <a href="#section-6.2">6.2</a>. Relationship to Other MIB Modules .........................<a href="#page-14">14</a>
           <a href="#section-6.2.1">6.2.1</a>. MIB Modules Required for IMPORTS ...................<a href="#page-15">15</a>
   <a href="#section-7">7</a>. MIB Module Definition ..........................................<a href="#page-15">15</a>
   <a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-20">20</a>
      <a href="#section-8.1">8.1</a>. MIB Module Security .......................................<a href="#page-20">20</a>
   <a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-21">21</a>
   <a href="#section-10">10</a>. Acknowledgments ...............................................<a href="#page-22">22</a>



<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   <a href="#section-11">11</a>. References ....................................................<a href="#page-22">22</a>
      <a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-22">22</a>
      <a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-23">23</a>
   <a href="#appendix-A">Appendix A</a>.  Notification Tables Configuration ....................<a href="#page-24">24</a>
     <a href="#appendix-A.1">A.1</a>.  Transport Security Model Processing for Notifications .....<a href="#page-25">25</a>
   <a href="#appendix-B">Appendix B</a>.  Processing Differences between USM and Secure
                Transport ............................................<a href="#page-26">26</a>
     <a href="#appendix-B.1">B.1</a>.  USM and the <a href="./rfc3411">RFC 3411</a> Architecture .........................<a href="#page-26">26</a>
     <a href="#appendix-B.2">B.2</a>.  Transport Subsystem and the <a href="./rfc3411">RFC 3411</a> Architecture .........<a href="#page-27">27</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This memo describes a Transport Security Model for the Simple Network
   Management Protocol for use with secure Transport Models in the
   Transport Subsystem [<a href="./rfc5590" title="&quot;Transport Subsystem for the Simple Network Management Protocol (SNMP)&quot;">RFC5590</a>].

   This memo also defines a portion of the Management Information Base
   (MIB) for monitoring and managing the Transport Security Model for
   SNMP.

   It is important to understand the SNMP architecture and the
   terminology of the architecture to understand where the Transport
   Security Model described in this memo fits into the architecture and
   interacts with other subsystems and models within the architecture.
   It is expected that readers will have also read and understood
   [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>], [<a href="./rfc3412" title="&quot;Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)&quot;">RFC3412</a>], [<a href="./rfc3413" title="&quot;Simple Network Management Protocol (SNMP) Applications&quot;">RFC3413</a>], and [<a href="./rfc3418" title="&quot;Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)&quot;">RFC3418</a>].

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  The Internet-Standard Management Framework</span>

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to <a href="./rfc3410#section-7">section&nbsp;7 of
   RFC 3410</a> [<a href="./rfc3410" title="&quot;Introduction and Applicability Statements for Internet- Standard Management Framework&quot;">RFC3410</a>].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   <a href="./rfc2578">RFC 2578</a> [<a href="./rfc2578" title="&quot;Structure of Management Information Version 2 (SMIv2)&quot;">RFC2578</a>], STD 58, <a href="./rfc2579">RFC 2579</a> [<a href="./rfc2579" title="&quot;Textual Conventions for SMIv2&quot;">RFC2579</a>] and STD 58, <a href="./rfc2580">RFC 2580</a>
   [<a href="./rfc2580" title="&quot;Conformance Statements for SMIv2&quot;">RFC2580</a>].

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Conventions</span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].




<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   Lowercase versions of the keywords should be read as in normal
   English.  They will usually, but not always, be used in a context
   that relates to compatibility with the <a href="./rfc3411">RFC 3411</a> architecture or the
   subsystem defined here but that might have no impact on on-the-wire
   compatibility.  These terms are used as guidance for designers of
   proposed IETF models to make the designs compatible with <a href="./rfc3411">RFC 3411</a>
   subsystems and Abstract Service Interfaces (ASIs).  Implementers are
   free to implement differently.  Some usages of these lowercase terms
   are simply normal English usage.

   For consistency with SNMP-related specifications, this document
   favors terminology as defined in STD 62, rather than favoring
   terminology that is consistent with non-SNMP specifications that use
   different variations of the same terminology.  This is consistent
   with the IESG decision to not require the SNMPv3 terminology be
   modified to match the usage of other non-SNMP specifications when
   SNMPv3 was advanced to Full Standard.

   Authentication in this document typically refers to the English
   meaning of "serving to prove the authenticity of" the message, not
   data source authentication or peer identity authentication.

   The terms "manager" and "agent" are not used in this document
   because, in the <a href="./rfc3411">RFC 3411</a> architecture, all SNMP entities have the
   capability of acting as manager, agent, or both depending on the SNMP
   applications included in the engine.  Where distinction is needed,
   the application names of command generator, command responder,
   notification originator, notification receiver, and proxy forwarder
   are used.  See "Simple Network Management Protocol (SNMP)
   Applications" [<a href="./rfc3413" title="&quot;Simple Network Management Protocol (SNMP) Applications&quot;">RFC3413</a>] for further information.

   While security protocols frequently refer to a user, the terminology
   used in [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>] and in this memo is "principal".  A principal is
   the "who" on whose behalf services are provided or processing takes
   place.  A principal can be, among other things, an individual acting
   in a particular role, a set of individuals each acting in a
   particular role, an application or a set of applications, or a
   combination of these within an administrative domain.

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  Modularity</span>

   The reader is expected to have read and understood the description of
   the SNMP architecture, as defined in [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>], and the architecture
   extension specified in "Transport Subsystem for the Simple Network
   Management Protocol (SNMP)" [<a href="./rfc5590" title="&quot;Transport Subsystem for the Simple Network Management Protocol (SNMP)&quot;">RFC5590</a>], which enables the use of
   external "lower-layer transport" protocols to provide message





<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   security.  Transport Models are tied into the SNMP architecture
   through the Transport Subsystem.  The Transport Security Model is
   designed to work with such lower-layer, secure Transport Models.

   In keeping with the <a href="./rfc3411">RFC 3411</a> design decisions to use self-contained
   documents, this memo includes the elements of procedure plus
   associated MIB objects that are needed for processing the Transport
   Security Model for SNMP.  These MIB objects SHOULD NOT be referenced
   in other documents.  This allows the Transport Security Model to be
   designed and documented as independent and self-contained, having no
   direct impact on other modules.  It also allows this module to be
   upgraded and supplemented as the need arises, and to move along the
   standards track on different time-lines from other modules.

   This modularity of specification is not meant to be interpreted as
   imposing any specific requirements on implementation.

<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>.  Motivation</span>

   This memo describes a Security Model to make use of Transport Models
   that use lower-layer, secure transports and existing and commonly
   deployed security infrastructures.  This Security Model is designed
   to meet the security and operational needs of network administrators,
   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 is possible.

<span class="h3"><a class="selflink" id="section-1.5" href="#section-1.5">1.5</a>.  Constraints</span>

   The design of this SNMP Security Model is also influenced by the
   following constraints:

   1.  In times of network stress, the security protocol and its
       underlying security mechanisms SHOULD NOT depend solely upon the
       ready availability of other network services (e.g., Network Time
       Protocol (NTP) or Authentication, Authorization, and Accounting
       (AAA) protocols).

   2.  When the network is not under stress, the Security Model and its
       underlying security mechanisms MAY depend upon the ready
       availability of other network services.

   3.  It might not be possible for the Security Model to determine when
       the network is under stress.

   4.  A Security Model SHOULD NOT require changes to the SNMP
       architecture.




<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   5.  A Security Model SHOULD NOT require changes to the underlying
       security protocol.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  How the Transport Security Model Fits in the Architecture</span>

   The Transport Security Model is designed to fit into the <a href="./rfc3411">RFC 3411</a>
   architecture as a Security Model in the Security Subsystem and to
   utilize the services of a secure Transport Model.

   For incoming messages, a secure Transport Model will pass a
   tmStateReference cache, described in [<a href="./rfc5590" title="&quot;Transport Subsystem for the Simple Network Management Protocol (SNMP)&quot;">RFC5590</a>].  To maintain <a href="./rfc3411">RFC 3411</a>
   modularity, the Transport Model will not know which securityModel
   will process the incoming message; the Message Processing Model will
   determine this.  If the Transport Security Model is used with a non-
   secure Transport Model, then the cache will not exist or will not be
   populated with security parameters, which will cause the Transport
   Security Model to return an error (see <a href="#section-5.2">Section 5.2</a>).

   The Transport Security Model will create the securityName and
   securityLevel to be passed to applications, and will verify that the
   tmTransportSecurityLevel reported by the Transport Model is at least
   as strong as the securityLevel requested by the Message Processing
   Model.

   For outgoing messages, the Transport Security Model will create a
   tmStateReference cache (or use an existing one), and will pass the
   tmStateReference to the specified Transport Model.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Security Capabilities of this Model</span>

<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>.  Threats</span>

   The Transport Security Model is compatible with the <a href="./rfc3411">RFC 3411</a>
   architecture and provides protection against the threats identified
   by the <a href="./rfc3411">RFC 3411</a> architecture.  However, the Transport Security Model
   does not provide security mechanisms such as authentication and
   encryption itself.  Which threats are addressed and how they are
   mitigated depends on the Transport Model used.  To avoid creating
   potential security vulnerabilities, operators should configure their
   system so this Security Model is always used with a Transport Model
   that provides appropriate security, where "appropriate" for a
   particular deployment is an administrative decision.









<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>.  Security Levels</span>

   The <a href="./rfc3411">RFC 3411</a> architecture recognizes three levels of security:

      - without authentication and without privacy (noAuthNoPriv)

      - with authentication but without privacy (authNoPriv)

      - with authentication and with privacy (authPriv)

   The model-independent securityLevel parameter is used to request
   specific levels of security for outgoing messages and to assert that
   specific levels of security were applied during the transport and
   processing of incoming messages.

   The transport-layer algorithms used to provide security should not be
   exposed to the Transport Security Model, as the Transport Security
   Model has no mechanisms by which it can test whether an assertion
   made by a Transport Model is accurate.

   The Transport Security Model trusts that the underlying secure
   transport connection has been properly configured to support security
   characteristics at least as strong as reported in
   tmTransportSecurityLevel.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Transport Sessions</span>

   The Transport Security Model does not work with transport sessions
   directly.  Instead the transport-related state is associated with a
   unique combination of transportDomain, transportAddress,
   securityName, and securityLevel, and is referenced via the
   tmStateReference parameter.  How and if this is mapped to a
   particular transport or channel is the responsibility of the
   Transport Subsystem.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Coexistence</span>

   In the <a href="./rfc3411">RFC 3411</a> architecture, a Message Processing Model determines
   which Security Model SHALL be called.  As of this writing, IANA has
   registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/
   SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1,
   SNMPv2c, and the User-based Security Model).

<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>.  Coexistence with Message Processing Models</span>

   The SNMPv1 and SNMPv2c message processing described in <a href="https://www.rfc-editor.org/bcp/bcp74">BCP 74</a>
   [<a href="./rfc3584" title="&quot;Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework&quot;">RFC3584</a>] always selects the SNMPv1(1) and SNMPv2c(2) Security
   Models.  Since there is no mechanism defined in <a href="./rfc3584">RFC 3584</a> to select an



<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   alternative Security Model, SNMPv1 and SNMPv2c messages cannot use
   the Transport Security Model.  Messages might still be able to be
   conveyed over a secure transport protocol, but the Transport Security
   Model will not be invoked.

   The SNMPv2u/SNMPv2* Message Processing Model is an historic artifact
   for which there is no existing IETF specification.

   The SNMPv3 message processing defined in [<a href="./rfc3412" title="&quot;Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)&quot;">RFC3412</a>] extracts the
   securityModel from the msgSecurityModel field of an incoming
   SNMPv3Message.  When this value is transportSecurityModel(4),
   security processing is directed to the Transport Security Model.  For
   an outgoing message to be secured using the Transport Security Model,
   the application MUST specify a securityModel parameter value of
   transportSecurityModel(4) in the sendPdu Abstract Service Interface
   (ASI).

<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>.  Coexistence with Other Security Models</span>

   The Transport Security Model uses its own MIB module for processing
   to maintain independence from other Security Models.  This allows the
   Transport Security Model to coexist with other Security Models, such
   as the User-based Security Model (USM) [<a href="./rfc3414" title="&quot;User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)&quot;">RFC3414</a>].

<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>.  Coexistence with Transport Models</span>

   The Transport Security Model (TSM) MAY work with multiple Transport
   Models, but the <a href="./rfc3411">RFC 3411</a> Abstract Service Interfaces (ASIs) do not
   carry a value for the Transport Model.  The MIB module defined in
   this memo allows an administrator to configure whether or not TSM
   prepends a Transport Model prefix to the securityName.  This will
   allow SNMP applications to consider Transport Model as a factor when
   making decisions, such as access control, notification generation,
   and proxy forwarding.

   To have SNMP properly utilize the security services coordinated by
   the Transport Security Model, this Security Model MUST only be used
   with Transport Models that know how to process a tmStateReference,
   such as the Secure Shell Transport Model [<a href="./rfc5592" title="&quot;Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)&quot;">RFC5592</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Cached Information and References</span>

   When performing SNMP processing, there are two levels of state
   information that might need to be retained: the immediate state
   linking a request-response pair and a potentially longer-term state
   relating to transport and security.  "Transport Subsystem for the
   Simple Network Management Protocol (SNMP)" [<a href="./rfc5590" title="&quot;Transport Subsystem for the Simple Network Management Protocol (SNMP)&quot;">RFC5590</a>] defines general
   requirements for caches and references.



<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   This document defines additional cache requirements related to the
   Transport Security Model.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Transport Security Model Cached Information</span>

   The Transport Security Model has specific responsibilities regarding
   the cached information.

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  securityStateReference</span>

   The Transport Security Model adds the tmStateReference received from
   the processIncomingMsg ASI to the securityStateReference.  This
   tmStateReference can then be retrieved during the generateResponseMsg
   ASI so that it can be passed back to the Transport Model.

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  tmStateReference</span>

   For outgoing messages, the Transport Security Model uses parameters
   provided by the SNMP application to look up or create a
   tmStateReference.

   For the Transport Security Model, the security parameters used for a
   response MUST be the same as those used for the corresponding
   request.  This Security Model uses the tmStateReference stored as
   part of the securityStateReference when appropriate.  For responses
   and reports, this Security Model sets the tmSameSecurity flag to true
   in the tmStateReference before passing it to a Transport Model.

   For incoming messages, the Transport Security Model uses parameters
   provided in the tmStateReference cache to establish a securityName,
   and to verify adequate security levels.

<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>.  Prefixes and securityNames</span>

   The SNMP-VIEW-BASED-ACM-MIB module [<a href="./rfc3415" title="&quot;View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)&quot;">RFC3415</a>], the SNMP-TARGET-MIB
   module [<a href="./rfc3413" title="&quot;Simple Network Management Protocol (SNMP) Applications&quot;">RFC3413</a>], and other MIB modules contain objects to configure
   security parameters for use by applications such as access control,
   notification generation, and proxy forwarding.

   Transport domains and their corresponding prefixes are coordinated
   via the IANA registry "SNMP Transport Domains".

   If snmpTsmConfigurationUsePrefix is set to true, then all
   securityNames provided by, or provided to, the Transport Security
   Model MUST include a valid transport domain prefix.






<span class="grey">Harrington &amp; Hardaker       Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   If snmpTsmConfigurationUsePrefix is set to false, then all
   securityNames provided by, or provided to, the Transport Security
   Model MUST NOT include a transport domain prefix.

   The tmSecurityName in the tmStateReference stored as part of the
   securityStateReference does not contain a prefix.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Processing an Outgoing Message</span>

   An error indication might return an Object Identifier (OID) and value
   for an incremented counter, a value for securityLevel, values for
   contextEngineID and contextName for the counter, and the
   securityStateReference, if this information is available at the point
   where the error is detected.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Security Processing for an Outgoing Message</span>

   This section describes the procedure followed by the Transport
   Security Model.

   The parameters needed for generating a message are supplied to the
   Security Model by the Message Processing Model via the
   generateRequestMsg() or the generateResponseMsg() ASI.  The Transport
   Subsystem architectural extension has added the transportDomain,
   transportAddress, and tmStateReference parameters to the original <a href="./rfc3411">RFC</a>
   <a href="./rfc3411">3411</a> ASIs.

    statusInformation =                -- success or errorIndication
          generateRequestMsg(
          IN   messageProcessingModel  -- typically, SNMP version
          IN   globalData              -- message header, admin data
          IN   maxMessageSize          -- of the sending SNMP entity
          IN   transportDomain         -- (NEW) specified by application
          IN   transportAddress        -- (NEW) specified by application
          IN   securityModel           -- for the outgoing message
          IN   securityEngineID        -- authoritative SNMP entity
          IN   securityName            -- on behalf of this principal
          IN   securityLevel           -- Level of Security requested
          IN   scopedPDU               -- message (plaintext) payload
          OUT  securityParameters      -- filled in by Security Module
          OUT  wholeMsg                -- complete generated message
          OUT  wholeMsgLength          -- length of generated message
          OUT  tmStateReference        -- (NEW) transport info
               )

  statusInformation = -- success or errorIndication
          generateResponseMsg(
          IN   messageProcessingModel  -- typically, SNMP version



<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


          IN   globalData              -- message header, admin data
          IN   maxMessageSize          -- of the sending SNMP entity
          IN   transportDomain         -- (NEW) specified by application
          IN   transportAddress        -- (NEW) specified by application
          IN   securityModel           -- for the outgoing message
          IN   securityEngineID        -- authoritative SNMP entity
          IN   securityName            -- on behalf of this principal
          IN   securityLevel           -- Level of Security requested
          IN   scopedPDU               -- message (plaintext) payload
          IN   securityStateReference  -- reference to security state
                                       -- information from original
                                       -- request
          OUT  securityParameters      -- filled in by Security Module
          OUT  wholeMsg                -- complete generated message
          OUT  wholeMsgLength          -- length of generated message
          OUT  tmStateReference        -- (NEW) transport info
               )

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Elements of Procedure for Outgoing Messages</span>

   1.  If there is a securityStateReference (Response or Report
       message), then this Security Model uses the cached information
       rather than the information provided by the ASI.  Extract the
       tmStateReference from the securityStateReference cache.  Set the
       tmRequestedSecurityLevel to the value of the extracted
       tmTransportSecurityLevel.  Set the tmSameSecurity parameter in
       the tmStateReference cache to true.  The cachedSecurityData for
       this message can now be discarded.

   2.  If there is no securityStateReference (e.g., a Request-type or
       Notification message), then create a tmStateReference cache.  Set
       tmTransportDomain to the value of transportDomain,
       tmTransportAddress to the value of transportAddress, and
       tmRequestedSecurityLevel to the value of securityLevel.
       (Implementers might optimize by pointing to saved copies of these
       session-specific values.)  Set the transaction-specific
       tmSameSecurity parameter to false.

       If the snmpTsmConfigurationUsePrefix object is set to false, then
       set tmSecurityName to the value of securityName.

       If the snmpTsmConfigurationUsePrefix object is set to true, then
       use the transportDomain to look up the corresponding prefix.
       (Since the securityStateReference stores the tmStateReference
       with the tmSecurityName for the incoming message, and since
       tmSecurityName never has a prefix, the prefix-stripping step only
       occurs when we are not using the securityStateReference).




<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


          If the prefix lookup fails for any reason, then the
          snmpTsmUnknownPrefixes counter is incremented, an error
          indication is returned to the calling module, and message
          processing stops.

          If the lookup succeeds, but there is no prefix in the
          securityName, or the prefix returned does not match the prefix
          in the securityName, or the length of the prefix is less than
          1 or greater than 4 US-ASCII alpha-numeric characters, then
          the snmpTsmInvalidPrefixes counter is incremented, an error
          indication is returned to the calling module, and message
          processing stops.

          Strip the transport-specific prefix and trailing ':' character
          (US-ASCII 0x3a) from the securityName.  Set tmSecurityName to
          the value of securityName.

   3.  Set securityParameters to a zero-length OCTET STRING ('0400').

   4.  Combine the message parts into a wholeMsg and calculate
       wholeMsgLength.

   5.  The wholeMsg, wholeMsgLength, securityParameters, and
       tmStateReference are returned to the calling Message Processing
       Model with the statusInformation set to success.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Processing an Incoming SNMP Message</span>

   An error indication might return an OID and value for an incremented
   counter, a value for securityLevel, values for contextEngineID and
   contextName for the counter, and the securityStateReference, if this
   information is available at the point where the error is detected.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Security Processing for an Incoming Message</span>

   This section describes the procedure followed by the Transport
   Security Model whenever it receives an incoming message from a
   Message Processing Model.  The ASI from a Message Processing Model to
   the Security Subsystem for a received message is:

   statusInformation =  -- errorIndication or success
                            -- error counter OID/value if error
   processIncomingMsg(
   IN   messageProcessingModel    -- typically, SNMP version
   IN   maxMessageSize            -- from the received message
   IN   securityParameters        -- from the received message
   IN   securityModel             -- from the received message
   IN   securityLevel             -- from the received message



<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   IN   wholeMsg                  -- as received on the wire
   IN   wholeMsgLength            -- length as received on the wire
   IN   tmStateReference          -- (NEW) from the Transport Model
   OUT  securityEngineID          -- authoritative SNMP entity
   OUT  securityName              -- identification of the principal
   OUT  scopedPDU,                -- message (plaintext) payload
   OUT  maxSizeResponseScopedPDU  -- maximum size sender can handle
   OUT  securityStateReference    -- reference to security state
    )                         -- information, needed for response

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Elements of Procedure for Incoming Messages</span>

   1.  Set the securityEngineID to the local snmpEngineID.

   2.  If tmStateReference does not refer to a cache containing values
       for tmTransportDomain, tmTransportAddress, tmSecurityName, and
       tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter
       is incremented, an error indication is returned to the calling
       module, and Security Model processing stops for this message.

   3.  Copy the tmSecurityName to securityName.

       If the snmpTsmConfigurationUsePrefix object is set to true, then
       use the tmTransportDomain to look up the corresponding prefix.

          If the prefix lookup fails for any reason, then the
          snmpTsmUnknownPrefixes counter is incremented, an error
          indication is returned to the calling module, and message
          processing stops.

          If the lookup succeeds but the prefix length is less than 1 or
          greater than 4 octets, then the snmpTsmInvalidPrefixes counter
          is incremented, an error indication is returned to the calling
          module, and message processing stops.

          Set the securityName to be the concatenation of the prefix, a
          ':' character (US-ASCII 0x3a), and the tmSecurityName.

   4.  Compare the value of tmTransportSecurityLevel in the
       tmStateReference cache to the value of the securityLevel
       parameter passed in the processIncomingMsg ASI.  If securityLevel
       specifies privacy (Priv) and tmTransportSecurityLevel specifies
       no privacy (noPriv), or if securityLevel specifies authentication
       (auth) and tmTransportSecurityLevel specifies no authentication
       (noAuth) was provided by the Transport Model, then the
       snmpTsmInadequateSecurityLevels counter is incremented, an error
       indication (unsupportedSecurityLevel) together with the OID and




<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


       value of the incremented counter is returned to the calling
       module, and Transport Security Model processing stops for this
       message.

   5.  The tmStateReference is cached as cachedSecurityData so that a
       possible response to this message will use the same security
       parameters.  Then securityStateReference is set for subsequent
       references to this cached data.

   6.  The scopedPDU component is extracted from the wholeMsg.

   7.  The maxSizeResponseScopedPDU is calculated.  This is the maximum
       size allowed for a scopedPDU for a possible Response message.

   8.  The statusInformation is set to success and a return is made to
       the calling module passing back the OUT parameters as specified
       in the processIncomingMsg ASI.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  MIB Module Overview</span>

   This MIB module provides objects for use only by the Transport
   Security Model.  It defines a configuration scalar and related error
   counters.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Structure of the MIB Module</span>

   Objects in this MIB module are arranged into subtrees.  Each subtree
   is organized as a set of related objects.  The overall structure and
   assignment of objects to their subtrees, and the intended purpose of
   each subtree, is shown below.

<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>.  The snmpTsmStats Subtree</span>

   This subtree contains error counters specific to the Transport
   Security Model.

<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>.  The snmpTsmConfiguration Subtree</span>

   This subtree contains a configuration object that enables
   administrators to specify if they want a transport domain prefix
   prepended to securityNames for use by applications.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Relationship to Other MIB Modules</span>

   Some management objects defined in other MIB modules are applicable
   to an entity implementing the Transport Security Model.  In
   particular, it is assumed that an entity implementing the Transport
   Security Model will implement the SNMP-FRAMEWORK-MIB [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>], the



<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   SNMP-TARGET-MIB [<a href="./rfc3413" title="&quot;Simple Network Management Protocol (SNMP) Applications&quot;">RFC3413</a>], the SNMP-VIEW-BASED-ACM-MIB [<a href="./rfc3415" title="&quot;View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)&quot;">RFC3415</a>], and
   the SNMPv2-MIB [<a href="./rfc3418" title="&quot;Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)&quot;">RFC3418</a>].  These are not needed to implement the
   SNMP-TSM-MIB.

<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>.  MIB Modules Required for IMPORTS</span>

   The following MIB module imports items from [<a href="./rfc2578" title="&quot;Structure of Management Information Version 2 (SMIv2)&quot;">RFC2578</a>], [<a href="./rfc2579" title="&quot;Textual Conventions for SMIv2&quot;">RFC2579</a>], and
   [<a href="./rfc2580" title="&quot;Conformance Statements for SMIv2&quot;">RFC2580</a>].

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  MIB Module Definition</span>

SNMP-TSM-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    mib-2, Counter32
      FROM SNMPv2-SMI -- <a href="./rfc2578">RFC2578</a>
    MODULE-COMPLIANCE, OBJECT-GROUP
      FROM SNMPv2-CONF -- <a href="./rfc2580">RFC2580</a>
    TruthValue
       FROM SNMPv2-TC -- <a href="./rfc2579">RFC2579</a>
    ;

snmpTsmMIB MODULE-IDENTITY
    LAST-UPDATED "200906090000Z"
    ORGANIZATION "ISMS Working Group"
    CONTACT-INFO "WG-EMail:   isms@lists.ietf.org
                  Subscribe:  isms-request@lists.ietf.org

                  Chairs:
                    Juergen Quittek
                    NEC Europe Ltd.
                    Network Laboratories
                    Kurfuersten-Anlage 36
                    69115 Heidelberg
                    Germany
                    +49 6221 90511-15
                    quittek@netlab.nec.de

                    Juergen Schoenwaelder
                    Jacobs University Bremen
                    Campus Ring 1
                    28725 Bremen
                    Germany
                    +49 421 200-3587
                    j.schoenwaelder@jacobs-university.de





<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


                  Editor:
                    David Harrington
                    Huawei Technologies USA
                    1700 Alma Dr.
                    Plano TX 75075
                    USA
                    +1 603-436-8634
                    ietfdbh@comcast.net

                    Wes Hardaker
                    Cobham Analytic Solutions
                    P.O. Box 382
                    Davis, CA  95617
                    USA
                    +1 530 792 1913
                    ietf@hardakers.net
                 "
    DESCRIPTION
       "The Transport Security Model MIB.

        In keeping with the <a href="./rfc3411">RFC 3411</a> design decisions to use
        self-contained documents, the RFC that contains the definition
        of this MIB module also includes the elements of procedure
        that are needed for processing the Transport Security Model
        for SNMP.  These MIB objects SHOULD NOT be modified via other
        subsystems or models defined in other documents.  This allows
        the Transport Security Model for SNMP to be designed and
        documented as independent and self-contained, having no direct
        impact on other modules, and this allows this module to be
        upgraded and supplemented as the need arises, and to move
        along the standards track on different time-lines from other
        modules.

        Copyright (c) 2009 IETF Trust and the persons
        identified as authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, are permitted provided that the
        following conditions are met:

        - Redistributions of source code must retain the above copyright
          notice, this list of conditions and the following disclaimer.

        - Redistributions in binary form must reproduce the above
          copyright notice, this list of conditions and the following
          disclaimer in the documentation and/or other materials
          provided with the distribution.




<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


        - Neither the name of Internet Society, IETF or IETF Trust,
          nor the names of specific contributors, may be used to endorse
          or promote products derived from this software without
          specific prior written permission.

        THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
        CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
        INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
        MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
        DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
        CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
        SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
        NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
        LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
        HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
        CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
        OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
        EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

        This version of this MIB module is part of <a href="./rfc5591">RFC 5591</a>;
        see the RFC itself for full legal notices."

    REVISION    "200906090000Z"
    DESCRIPTION "The initial version, published in <a href="./rfc5591">RFC 5591</a>."

    ::= { mib-2 190 }

-- ---------------------------------------------------------- --
-- subtrees in the SNMP-TSM-MIB
-- ---------------------------------------------------------- --

snmpTsmNotifications OBJECT IDENTIFIER ::= { snmpTsmMIB 0 }
snmpTsmMIBObjects    OBJECT IDENTIFIER ::= { snmpTsmMIB 1 }
snmpTsmConformance   OBJECT IDENTIFIER ::= { snmpTsmMIB 2 }

-- -------------------------------------------------------------
-- Objects
-- -------------------------------------------------------------

-- Statistics for the Transport Security Model

snmpTsmStats         OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 1 }

snmpTsmInvalidCaches OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of incoming messages dropped because the



<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


                 tmStateReference referred to an invalid cache.
                "
    ::= { snmpTsmStats 1 }

snmpTsmInadequateSecurityLevels OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of incoming messages dropped because
                 the securityLevel asserted by the Transport Model was
                 less than the securityLevel requested by the
                 application.
                "
    ::= { snmpTsmStats 2 }

snmpTsmUnknownPrefixes OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of messages dropped because
                 snmpTsmConfigurationUsePrefix was set to true and
                 there is no known prefix for the specified transport
                 domain.
                "
    ::= { snmpTsmStats 3 }

snmpTsmInvalidPrefixes OBJECT-TYPE
    SYNTAX       Counter32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of messages dropped because
                 the securityName associated with an outgoing message
                 did not contain a valid transport domain prefix.
                "
    ::= { snmpTsmStats 4 }

-- -------------------------------------------------------------
-- Configuration
-- -------------------------------------------------------------

-- Configuration for the Transport Security Model

snmpTsmConfiguration   OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 2 }

snmpTsmConfigurationUsePrefix OBJECT-TYPE
    SYNTAX      TruthValue
    MAX-ACCESS  read-write
    STATUS      current



<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


    DESCRIPTION "If this object is set to true, then securityNames
                 passing to and from the application are expected to
                 contain a transport-domain-specific prefix.  If this
                 object is set to true, then a domain-specific prefix
                 will be added by the TSM to the securityName for
                 incoming messages and removed from the securityName
                 when processing outgoing messages.  Transport domains
                 and prefixes are maintained in a registry by IANA.
                 This object SHOULD persist across system reboots.
                "
    DEFVAL { false }
    ::= { snmpTsmConfiguration 1 }

-- -------------------------------------------------------------
-- snmpTsmMIB - Conformance Information
-- -------------------------------------------------------------

snmpTsmCompliances OBJECT IDENTIFIER ::= { snmpTsmConformance 1 }

snmpTsmGroups      OBJECT IDENTIFIER ::= { snmpTsmConformance 2 }

-- -------------------------------------------------------------
-- Compliance statements
-- -------------------------------------------------------------

snmpTsmCompliance MODULE-COMPLIANCE
    STATUS      current
    DESCRIPTION "The compliance statement for SNMP engines that support
                 the SNMP-TSM-MIB.
                "
    MODULE
        MANDATORY-GROUPS { snmpTsmGroup }
    ::= { snmpTsmCompliances 1 }

-- -------------------------------------------------------------
-- Units of conformance
-- -------------------------------------------------------------
snmpTsmGroup OBJECT-GROUP
    OBJECTS {
        snmpTsmInvalidCaches,
        snmpTsmInadequateSecurityLevels,
        snmpTsmUnknownPrefixes,
        snmpTsmInvalidPrefixes,
        snmpTsmConfigurationUsePrefix
    }
    STATUS      current
    DESCRIPTION "A collection of objects for maintaining
                 information of an SNMP engine that implements



<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


                 the SNMP Transport Security Model.
                "

    ::= { snmpTsmGroups 2 }

END

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Security Considerations</span>

   This document describes a Security Model, compatible with the <a href="./rfc3411">RFC</a>
   <a href="./rfc3411">3411</a> architecture, that permits SNMP to utilize security services
   provided through an SNMP Transport Model.  The Transport Security
   Model relies on Transport Models for mutual authentication, binding
   of keys, confidentiality, and integrity.

   The Transport Security Model relies on secure Transport Models to
   provide an authenticated principal identifier and an assertion of
   whether authentication and privacy are used during transport.  This
   Security Model SHOULD always be used with Transport Models that
   provide adequate security, but "adequate security" is a configuration
   and/or run-time decision of the operator or management application.
   The security threats and how these threats are mitigated should be
   covered in detail in the specifications of the Transport Models and
   the underlying secure transports.

   An authenticated principal identifier (securityName) is used in SNMP
   applications for purposes such as access control, notification
   generation, and proxy forwarding.  This Security Model supports
   multiple Transport Models.  Operators might judge some transports to
   be more secure than others, so this Security Model can be configured
   to prepend a prefix to the securityName to indicate the Transport
   Model used to authenticate the principal.  Operators can use the
   prefixed securityName when making application decisions about levels
   of access.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  MIB Module Security</span>

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:







<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   o  The snmpTsmConfigurationUsePrefix object could be modified,
      creating a denial of service or authorizing SNMP messages that
      would not have previously been authorized by an Access Control
      Model (e.g., the View-based Access Control Model (VACM)).

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   o  All the counters in this module refer to configuration errors and
      do not expose sensitive information.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see <a href="./rfc3410#section-8">[RFC3410], section&nbsp;8</a>),
   including full support for the USM and Transport Security Model
   cryptographic mechanisms (for authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  IANA Considerations</span>

   IANA has assigned:

   1.  An SMI number (190) with a prefix of mib-2 in the MIB module
       registry for the MIB module in this document.

   2.  A value (4) to identify the Transport Security Model, in the
       Security Models registry of the SNMP Number Spaces registry.
       This results in the following table of values:






<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   Value   Description                         References
   -----   -----------                         ----------
     0     reserved for 'any'                  [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>]
     1     reserved for SNMPv1                 [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>]
     2     reserved for SNMPv2c                [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>]
     3     User-Based Security Model (USM)     [<a href="./rfc3411" title="&quot;An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks&quot;">RFC3411</a>]
     4     Transport Security Model (TSM)      [<a href="./rfc5591">RFC5591</a>]

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Acknowledgments</span>

   The editors would like to thank Jeffrey Hutzelman for sharing his SSH
   insights and Dave Shield for an outstanding job wordsmithing the
   existing document to improve organization and clarity.

   Additionally, helpful document reviews were received from Juergen
   Schoenwaelder.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  References</span>

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2578">RFC2578</a>]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, <a href="./rfc2578">RFC 2578</a>, April 1999.

   [<a id="ref-RFC2579">RFC2579</a>]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, <a href="./rfc2579">RFC 2579</a>, April 1999.

   [<a id="ref-RFC2580">RFC2580</a>]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, <a href="./rfc2580">RFC 2580</a>,
              April 1999.

   [<a id="ref-RFC3411">RFC3411</a>]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, <a href="./rfc3411">RFC 3411</a>,
              December 2002.

   [<a id="ref-RFC3412">RFC3412</a>]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
              "Message Processing and Dispatching for the Simple Network
              Management Protocol (SNMP)", STD 62, <a href="./rfc3412">RFC 3412</a>,
              December 2002.






<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   [<a id="ref-RFC3413">RFC3413</a>]  Levi, D., Meyer, P., and B. Stewart, "Simple Network
              Management Protocol (SNMP) Applications", STD 62,
              <a href="./rfc3413">RFC 3413</a>, December 2002.

   [<a id="ref-RFC3414">RFC3414</a>]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, <a href="./rfc3414">RFC 3414</a>, December 2002.

   [<a id="ref-RFC5590">RFC5590</a>]  Harrington, D. and J. Schoenwaelder, "Transport Subsystem
              for the Simple Network Management Protocol (SNMP)",
              <a href="./rfc5590">RFC 5590</a>, June 2009.

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Informative References</span>

   [<a id="ref-RFC3410">RFC3410</a>]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", <a href="./rfc3410">RFC 3410</a>, December 2002.

   [<a id="ref-RFC3415">RFC3415</a>]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", STD 62, <a href="./rfc3415">RFC 3415</a>,
              December 2002.

   [<a id="ref-RFC3418">RFC3418</a>]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62,
              <a href="./rfc3418">RFC 3418</a>, December 2002.

   [<a id="ref-RFC3584">RFC3584</a>]  Frye, R., Levi, D., Routhier, S., and B. Wijnen,
              "Coexistence between Version 1, Version 2, and Version 3
              of the Internet-standard Network Management Framework",
              <a href="https://www.rfc-editor.org/bcp/bcp74">BCP 74</a>, <a href="./rfc3584">RFC 3584</a>, August 2003.

   [<a id="ref-RFC5592">RFC5592</a>]  Harrington, D., Salowey, J., and W. Hardaker, "Secure
              Shell Transport Model for the Simple Network Management
              Protocol (SNMP)", <a href="./rfc5592">RFC 5592</a>, June 2009.
















<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Notification Tables Configuration</span>

   The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [<a href="./rfc3413" title="&quot;Simple Network Management Protocol (SNMP) Applications&quot;">RFC3413</a>] are used to
   configure notification originators with the destinations to which
   notifications should be sent.

   Most of the configuration is Security-Model-independent and
   Transport-Model-independent.

   The values we will use in the examples for the five model-independent
   security and transport parameters are:

      transportDomain = snmpSSHDomain

      transportAddress = 192.0.2.1:5162

      securityModel = Transport Security Model

      securityName = alice

      securityLevel = authPriv

   The following example will configure the notification originator to
   send informs to a notification receiver at 192.0.2.1:5162 using the
   securityName "alice". "alice" is the name for the recipient from the
   standpoint of the notification originator and is used for processing
   access controls before sending a notification.

   The columns marked with an "*" are the items that are Security-Model-
   specific or Transport-Model-specific.

   The configuration for the "alice" settings in the SNMP-VIEW-BASED-
   ACM-MIB objects are not shown here for brevity.  First, we configure
   which type of notification will be sent for this taglist (toCRTag).
   In this example, we choose to send an Inform.
     snmpNotifyTable row:
          snmpNotifyName                 CRNotif
          snmpNotifyTag                  toCRTag
          snmpNotifyType                 inform
          snmpNotifyStorageType          nonVolatile
          snmpNotifyColumnStatus         createAndGo

   Then we configure a transport address to which notifications
   associated with this taglist will be sent, and we specify which
   snmpTargetParamsEntry will be used (toCR) when sending to this
   transport address.





<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


          snmpTargetAddrTable row:
             snmpTargetAddrName              toCRAddr
         *   snmpTargetAddrTDomain           snmpSSHDomain
         *   snmpTargetAddrTAddress          192.0.2.1:5162
             snmpTargetAddrTimeout           1500
             snmpTargetAddrRetryCount        3
             snmpTargetAddrTagList           toCRTag
             snmpTargetAddrParams            toCR   (MUST match below)
             snmpTargetAddrStorageType       nonVolatile
             snmpTargetAddrColumnStatus      createAndGo

   Then we configure which principal at the host will receive the
   notifications associated with this taglist.  Here, we choose "alice",
   who uses the Transport Security Model.
         snmpTargetParamsTable row:
             snmpTargetParamsName            toCR
             snmpTargetParamsMPModel         SNMPv3
         *   snmpTargetParamsSecurityModel   TransportSecurityModel
             snmpTargetParamsSecurityName    "alice"
             snmpTargetParamsSecurityLevel   authPriv
             snmpTargetParamsStorageType     nonVolatile
             snmpTargetParamsRowStatus       createAndGo


<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  Transport Security Model Processing for Notifications</span>

   The Transport Security Model is called using the generateRequestMsg()
   ASI, with the following parameters (those with an * are from the
   above tables):

    statusInformation =                -- success or errorIndication
          generateRequestMsg(
          IN   messageProcessingModel  -- *snmpTargetParamsMPModel
          IN   globalData              -- message header, admin data
          IN   maxMessageSize          -- of the sending SNMP entity
          IN   transportDomain         -- *snmpTargetAddrTDomain
          IN   transportAddress        -- *snmpTargetAddrTAddress
          IN   securityModel           -- *snmpTargetParamsSecurityModel
          IN   securityEngineID        -- immaterial; TSM will ignore.
          IN   securityName            -- snmpTargetParamsSecurityName
          IN   securityLevel           -- *snmpTargetParamsSecurityLevel
          IN   scopedPDU               -- message (plaintext) payload
          OUT  securityParameters      -- filled in by Security Module
          OUT  wholeMsg                -- complete generated message
          OUT  wholeMsgLength          -- length of generated message
          OUT  tmStateReference        -- reference to transport info
               )




<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   The Transport Security Model will determine the Transport Model based
   on the snmpTargetAddrTDomain.  The selected Transport Model will
   select the appropriate transport connection using the
   tmStateReference cache created from the values of
   snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and
   snmpTargetParamsSecurityLevel.

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Processing Differences between USM and Secure Transport</span>

   USM and secure transports differ in the processing order and
   responsibilities within the <a href="./rfc3411">RFC 3411</a> architecture.  While the steps
   are the same, they occur in a different order and might be done by
   different subsystems.  The following lists illustrate the difference
   in the flow and the responsibility for different processing steps for
   incoming messages when using USM and when using a secure transport.
   (These lists are simplified for illustrative purposes, and do not
   represent all details of processing.  Transport Models MUST provide
   the detailed elements of procedure.)

   With USM, SNMPv1, and SNMPv2c Security Models, security processing
   starts when the Message Processing Model decodes portions of the
   ASN.1 message to extract header fields that are used to determine
   which Security Model will process the message to perform
   authentication, decryption, timeliness checking, integrity checking,
   and translation of parameters to model-independent parameters.  By
   comparison, a secure transport performs those security functions on
   the message, before the ASN.1 is decoded.

   Step 6 cannot occur until after decryption occurs.  Steps 6 and
   beyond are the same for USM and a secure transport.

<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>.  USM and the <a href="./rfc3411">RFC 3411</a> Architecture</span>

   1) Decode the ASN.1 header (Message Processing Model).

   2) Determine the SNMP Security Model and parameters (Message
      Processing Model).

   3) Verify securityLevel (Security Model).

   4) Translate parameters to model-independent parameters (Security
      Model).

   5) Authenticate the principal, check message integrity and
      timeliness, and decrypt the message (Security Model).






<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


   6) Determine the pduType in the decrypted portions (Message
      Processing Model).

   7) Pass on the decrypted portions with model-independent parameters.

<span class="h3"><a class="selflink" id="appendix-B.2" href="#appendix-B.2">B.2</a>.  Transport Subsystem and the <a href="./rfc3411">RFC 3411</a> Architecture</span>

   1) Authenticate the principal, check integrity and timeliness of the
      message, and decrypt the message (Transport Model).

   2) Translate parameters to model-independent parameters (Transport
      Model).

   3) Decode the ASN.1 header (Message Processing Model).

   4) Determine the SNMP Security Model and parameters (Message
      Processing Model).

   5) Verify securityLevel (Security Model).

   6) Determine the pduType in the decrypted portions (Message
      Processing Model).

   7) Pass on the decrypted portions with model-independent security
      parameters.

   If a message is secured using a secure transport layer, then the
   Transport Model will provide the translation from the authenticated
   identity (e.g., an SSH user name) to a human-friendly identifier
   (tmSecurityName) in step 2.  The Security Model will provide a
   mapping from that identifier to a model-independent securityName.




















<span class="grey">Harrington &amp; Hardaker       Standards Track                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc5591">RFC 5591</a>           Transport Security Model for SNMP           June 2009</span>


Authors' Addresses

   David Harrington
   Huawei Technologies (USA)
   1700 Alma Dr. Suite 100
   Plano, TX 75075
   USA

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


   Wes Hardaker
   Cobham Analytic Solutions
   P.O. Box 382
   Davis, CA  95617
   US

   Phone: +1 530 792 1913
   EMail: ietf@hardakers.net































Harrington &amp; Hardaker       Standards Track                    [Page 28]
</pre>