Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 6353

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

Pages: 65
Internet Standard: 78
STD 78 is also:  534355905591
Obsoletes:  5953
Part 1 of 4 – Pages 1 to 8
None   None   Next

Top   ToC   RFC6353 - Page 1
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.
Top   ToC   RFC6353 - Page 2
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
Top   ToC   RFC6353 - Page 3
     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
Top   ToC   RFC6353 - Page 4

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].
Top   ToC   RFC6353 - Page 5
   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].
Top   ToC   RFC6353 - Page 6
 +---------------------------------------------------------------------+
 |                              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 |
 +---------------------------------+ +---------------------------------+
Top   ToC   RFC6353 - Page 7

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.
Top   ToC   RFC6353 - Page 8
   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.


(page 8 continued on part 2)

Next Section