Internet Engineering Task Force (IETF)                       W. Hardaker
Request for Comments: 6353                                  SPARTA, Inc.
Obsoletes: 5953                                                July 2011
Category: Standards Track
ISSN: 2070-1721


           Transport Layer Security (TLS) Transport Model for
             the Simple Network Management Protocol (SNMP)

Abstract

   This document describes a Transport Model for the Simple Network
   Management Protocol (SNMP), that uses either the Transport Layer
   Security protocol or the Datagram Transport Layer Security (DTLS)
   protocol.  The TLS and DTLS protocols provide authentication and
   privacy services for SNMP applications.  This document describes how
   the TLS Transport Model (TLSTM) implements the needed features of an
   SNMP Transport Subsystem to make this protection possible in an
   interoperable way.

   This Transport Model is designed to meet the security and operational
   needs of network administrators.  It supports the sending of SNMP
   messages over TLS/TCP and DTLS/UDP.  The TLS mode can make use of
   TCP's improved support for larger packet sizes and the DTLS mode
   provides potentially superior operation in environments where a
   connectionless (e.g., UDP) transport is preferred.  Both TLS and DTLS
   integrate well into existing public keying infrastructures.

   This document also defines a portion of the Management Information
   Base (MIB) for use with network management protocols.  In particular,
   it defines objects for managing the TLS Transport Model for SNMP.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6353.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  7
     1.2.  Changes Since RFC 5953 . . . . . . . . . . . . . . . . . .  8
   2.  The Transport Layer Security Protocol  . . . . . . . . . . . .  8
   3.  How the TLSTM Fits into the Transport Subsystem  . . . . . . .  8
     3.1.  Security Capabilities of This Model  . . . . . . . . . . . 11
       3.1.1.  Threats  . . . . . . . . . . . . . . . . . . . . . . . 11
       3.1.2.  Message Protection . . . . . . . . . . . . . . . . . . 12
       3.1.3.  (D)TLS Connections . . . . . . . . . . . . . . . . . . 13
     3.2.  Security Parameter Passing . . . . . . . . . . . . . . . . 14
     3.3.  Notifications and Proxy  . . . . . . . . . . . . . . . . . 14
   4.  Elements of the Model  . . . . . . . . . . . . . . . . . . . . 15
     4.1.  X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15
       4.1.1.  Provisioning for the Certificate . . . . . . . . . . . 15
     4.2.  (D)TLS Usage . . . . . . . . . . . . . . . . . . . . . . . 17
     4.3.  SNMP Services  . . . . . . . . . . . . . . . . . . . . . . 18
       4.3.1.  SNMP Services for an Outgoing Message  . . . . . . . . 18
       4.3.2.  SNMP Services for an Incoming Message  . . . . . . . . 19

     4.4.  Cached Information and References  . . . . . . . . . . . . 20
       4.4.1.  TLS Transport Model Cached Information . . . . . . . . 20
         4.4.1.1.  tmSecurityName . . . . . . . . . . . . . . . . . . 20
         4.4.1.2.  tmSessionID  . . . . . . . . . . . . . . . . . . . 21
         4.4.1.3.  Session State  . . . . . . . . . . . . . . . . . . 21
   5.  Elements of Procedure  . . . . . . . . . . . . . . . . . . . . 21
     5.1.  Procedures for an Incoming Message . . . . . . . . . . . . 21
       5.1.1.  DTLS over UDP Processing for Incoming Messages . . . . 22
       5.1.2.  Transport Processing for Incoming SNMP Messages  . . . 23
     5.2.  Procedures for an Outgoing SNMP Message  . . . . . . . . . 25
     5.3.  Establishing or Accepting a Session  . . . . . . . . . . . 26
       5.3.1.  Establishing a Session as a Client . . . . . . . . . . 26
       5.3.2.  Accepting a Session as a Server  . . . . . . . . . . . 28
     5.4.  Closing a Session  . . . . . . . . . . . . . . . . . . . . 29
   6.  MIB Module Overview  . . . . . . . . . . . . . . . . . . . . . 30
     6.1.  Structure of the MIB Module  . . . . . . . . . . . . . . . 30
     6.2.  Textual Conventions  . . . . . . . . . . . . . . . . . . . 30
     6.3.  Statistical Counters . . . . . . . . . . . . . . . . . . . 30
     6.4.  Configuration Tables . . . . . . . . . . . . . . . . . . . 30
       6.4.1.  Notifications  . . . . . . . . . . . . . . . . . . . . 31
     6.5.  Relationship to Other MIB Modules  . . . . . . . . . . . . 31
       6.5.1.  MIB Modules Required for IMPORTS . . . . . . . . . . . 31
   7.  MIB Module Definition  . . . . . . . . . . . . . . . . . . . . 31
   8.  Operational Considerations . . . . . . . . . . . . . . . . . . 54
     8.1.  Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 54
     8.2.  Notification Receiver Credential Selection . . . . . . . . 54
     8.3.  contextEngineID Discovery  . . . . . . . . . . . . . . . . 55
     8.4.  Transport Considerations . . . . . . . . . . . . . . . . . 55
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 55
     9.1.  Certificates, Authentication, and Authorization  . . . . . 55
     9.2.  (D)TLS Security Considerations . . . . . . . . . . . . . . 56
       9.2.1.  TLS Version Requirements . . . . . . . . . . . . . . . 56
       9.2.2.  Perfect Forward Secrecy  . . . . . . . . . . . . . . . 57
     9.3.  Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 57
     9.4.  MIB Module Security  . . . . . . . . . . . . . . . . . . . 57
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 59
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 60
     12.2. Informative References . . . . . . . . . . . . . . . . . . 61
   Appendix A.  Target and Notification Configuration Example . . . . 63
     A.1.  Configuring a Notification Originator  . . . . . . . . . . 63
     A.2.  Configuring TLSTM to Utilize a Simple Derivation of
           tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 64
     A.3.  Configuring TLSTM to Utilize Table-Driven Certificate
           Mapping  . . . . . . . . . . . . . . . . . . . . . . . . . 64

1.  Introduction

   It is important to understand the modular SNMPv3 architecture as
   defined by [RFC3411] and enhanced by the Transport Subsystem
   [RFC5590].  It is also important to understand the terminology of the
   SNMPv3 architecture in order to understand where the Transport Model
   described in this document fits into the architecture and how it
   interacts with the other architecture subsystems.  For a detailed
   overview of the documents that describe the current Internet-Standard
   Management Framework, please refer to Section 7 of [RFC3410].

   This document describes a Transport Model that makes use of the
   Transport Layer Security (TLS) [RFC5246] and the Datagram Transport
   Layer Security (DTLS) Protocol [RFC4347], within a Transport
   Subsystem [RFC5590].  DTLS is the datagram variant of the Transport
   Layer Security (TLS) protocol [RFC5246].  The Transport Model in this
   document is referred to as the Transport Layer Security Transport
   Model (TLSTM).  TLS and DTLS take advantage of the X.509 public
   keying infrastructure [RFC5280].  While (D)TLS supports multiple
   authentication mechanisms, this document only discusses X.509
   certificate-based authentication.  Although other forms of
   authentication are possible, they are outside the scope of this
   specification.  This transport model is designed to meet the security
   and operational needs of network administrators, operating in both
   environments where a connectionless (e.g., UDP) transport is
   preferred and in environments where large quantities of data need to
   be sent (e.g., over a TCP-based stream).  Both TLS and DTLS integrate
   well into existing public keying infrastructures.  This document
   supports sending of SNMP messages over TLS/TCP and DTLS/UDP.

   This document also defines a portion of the Management Information
   Base (MIB) for use with network management protocols.  In particular,
   it defines objects for managing the TLS Transport Model for SNMP.

   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:
   [RFC2578], [RFC2579], and [RFC2580].

   The diagram shown below gives a conceptual overview of two SNMP
   entities communicating using the TLS Transport Model (shown as
   "TLSTM").  One entity contains a command responder and notification
   originator application, and the other a command generator and
   notification receiver application.  It should be understood that this
   particular mix of application types is an example only and other
   combinations are equally valid.

   Note: this diagram shows the Transport Security Model (TSM) being
   used as the security model that is defined in [RFC5591].

 +---------------------------------------------------------------------+
 |                              Network                                |
 +---------------------------------------------------------------------+
     ^                     |            ^               |
     |Notifications        |Commands    |Commands       |Notifications
 +---|---------------------|-------+ +--|---------------|--------------+
 |   |                     V       | |  |               V              |
 | +------------+  +------------+  | | +-----------+   +----------+    |
 | |  (D)TLS    |  |  (D)TLS    |  | | | (D)TLS    |   | (D)TLS   |    |
 | |  (Client)  |  |  (Server)  |  | | | (Client)  |   | (Server) |    |
 | +------------+  +------------+  | | +-----------+   +----------+    |
 |       ^             ^           | |       ^              ^          |
 |       |             |           | |       |              |          |
 |       +-------------+           | |       +--------------+          |
 | +-----|------------+            | | +-----|------------+            |
 | |     V            |            | | |     V            |            |
 | | +--------+       |   +-----+  | | | +--------+       |   +-----+  |
 | | | TLS TM |<--------->|Cache|  | | | | TLS TM |<--------->|Cache|  |
 | | +--------+       |   +-----+  | | | +--------+       |   +-----+  |
 | |Transport Subsys. |      ^     | | |Transport Subsys. |      ^     |
 | +------------------+      |     | | +------------------+      |     |
 |    ^                      |     | |    ^                      |     |
 |    |                      +--+  | |    |                      +--+  |
 |    v                         |  | |    V                         |  |
 | +-----+ +--------+ +-------+ |  | | +-----+ +--------+ +-------+ |  |
 | |     | |Message | |Securi.| |  | | |     | |Message | |Securi.| |  |
 | |Disp.| |Proc.   | |Subsys.| |  | | |Disp.| |Proc.   | |Subsys.| |  |
 | |     | |Subsys. | |       | |  | | |     | |Subsys. | |       | |  |
 | |     | |        | |       | |  | | |     | |        | |       | |  |
 | |     | | +----+ | | +---+ | |  | | |     | | +----+ | | +---+ | |  |
 | |    <--->|v3MP|<--> |TSM|<--+  | | |    <--->|v3MP|<--->|TSM|<--+  |
 | |     | | +----+ | | +---+ |    | | |     | | +----+ | | +---+ |    |
 | |     | |        | |       |    | | |     | |        | |       |    |
 | +-----+ +--------+ +-------+    | | +-----+ +--------+ +-------+    |
 |    ^                            | |    ^                            |
 |    |                            | |    |                            |
 |    +-+------------+             | |    +-+----------+               |
 |      |            |             | |      |          |               |
 |      v            v             | |      v          V               |
 | +-------------+ +-------------+ | | +-------------+ +-------------+ |
 | |   COMMAND   | | NOTIFICAT.  | | | |  COMMAND    | | NOTIFICAT.  | |
 | |  RESPONDER  | | ORIGINATOR  | | | | GENERATOR   | | RECEIVER    | |
 | | application | | application | | | | application | | application | |
 | +-------------+ +-------------+ | | +-------------+ +-------------+ |
 |                     SNMP entity | |                     SNMP entity |
 +---------------------------------+ +---------------------------------+

1.1.  Conventions

   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.  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 a 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 [RFC3411] architecture, all SNMP entities have the
   capability of acting as manager, agent, or both depending on the SNMP
   application types supported in the implementation.  Where distinction
   is required, the application names of command generator, command
   responder, notification originator, notification receiver, and proxy
   forwarder are used.  See "SNMP Applications" [RFC3413] for further
   information.

   Large portions of this document simultaneously refer to both TLS and
   DTLS when discussing TLSTM components that function equally with
   either protocol.  "(D)TLS" is used in these places to indicate that
   the statement applies to either or both protocols as appropriate.
   When a distinction between the protocols is needed, they are referred
   to independently through the use of "TLS" or "DTLS".  The Transport
   Model, however, is named "TLS Transport Model" and refers not to the
   TLS or DTLS protocol but to the specification in this document, which
   includes support for both TLS and DTLS.

   Throughout this document, the terms "client" and "server" are used to
   refer to the two ends of the (D)TLS transport connection.  The client
   actively opens the (D)TLS connection, and the server passively
   listens for the incoming (D)TLS connection.  An SNMP entity may act
   as a (D)TLS client or server or both, depending on the SNMP
   applications supported.

   The User-Based Security Model (USM) [RFC3414] is a mandatory-to-
   implement Security Model in STD 62.  While (D)TLS and USM frequently
   refer to a user, the terminology preferred in RFC 3411 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, with each acting in a particular role; an application
   or a set of applications, or a combination of these within an
   administrative domain.

   Throughout this document, the term "session" is used to refer to a
   secure association between two TLS Transport Models that permits the
   transmission of one or more SNMP messages within the lifetime of the
   session.  The (D)TLS protocols also have an internal notion of a
   session and although these two concepts of a session are related,
   when the term "session" is used this document is referring to the
   TLSTM's specific session and not directly to the (D)TLS protocol's
   session.

   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 [RFC2119].

1.2.  Changes Since RFC 5953

   This document obsoletes [RFC5953].

   Since the publication of RFC 5953, a few editorial errata have been
   noted.  These errata are posted on the RFC Editor web site.  These
   errors have been corrected in this document.

   This document updates the references to RFC 3490 (IDNA 2003) to
   [RFC5890] (IDNA 2008), because RFC 3490 was obsoleted by RFC 5890.

   References to RFC 1033 were replaced with references to [RFC1123].

   Added informative reference to 5953.

   Updated MIB dates and revision date.

2.  The Transport Layer Security Protocol

   (D)TLS provides authentication, data message integrity, and privacy
   at the transport layer (see [RFC4347]).

   The primary goals of the TLS Transport Model are to provide privacy,
   peer identity authentication, and data integrity between two
   communicating SNMP entities.  The TLS and DTLS protocols provide a
   secure transport upon which the TLSTM is based.  Please refer to
   [RFC5246] and [RFC4347] for complete descriptions of the protocols.